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SIMSCRIPT II.5 with SIMGRAPHICS 

Simulation models are now easier to build 
-results are easier to understand 


N ow you can provide the users 
of your SIMSCRIPT II.5 
models with SIMGRAPHICS™ 
-graphical input and animation. 

SIMSCRIPT 11.5 gives you a 
compact English-like language. 
Your simulation program reads like 
a description of the system you are 
studying. 

With SIMGRAPHICS, results 
are easy to understand-animated 
pictures, histograms, pie charts and 
plots. 

Because your animated simula¬ 
tion results are easily understood, 
your recommendations are more 
likely to be acted upon. 

Free applications booklet 
A new booklet describing suc¬ 
cessful applications of SIMSCRIPT 
II.5® is now available. Typical ap¬ 
plications include: military plan¬ 
ning, manufacturing, communica¬ 
tions, logistics, and transportation. 

SIMSCRIPT II.5 is available on 
most popular computers including 
PC’s and Workstations. 


Free trial offer 

The free trial contains every¬ 
thing you need to try SIMSCRIPT 
II.5 on your computer. 

Try the SIMSCRIPT II.5 lan¬ 
guage, the built-in graphics, the 
quality and timeliness of our sup¬ 
port, and the accuracy of our 
documentation -everything you 
need for a successful project. 

For over 29 years CACI has 
provided trial use of its simulation 
software-no cost, no obligation. 
Act now-free training offer 

For a limited time we also in¬ 
clude free training. Call today to 
avoid disappointment-class size is 
limited. 

For immediate information 

Call Doug Dittrich at (619) 
457-9681, or Fax (619) 457-1184. 

In Canada, call Peter Holt on 
(613) 782-2474, Fax (613) 

782-2202. In Europe, call Nigel 
McNamara, in the UK, on 0276 
671 671, Fax 0276 670 677. 
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HOT Chips TV 


A Symposium on High-Performance Chips 


Stanford University, Stanford, California — August 9-11, 1992 

Attend HOT Chips IV, a symposium on high-performance chips, which will bring together researchers and developers of 
chips used to construct high-performance workstations and systems. Enjoy the informal format offering interaction with 
speakers. The first three HOT Chips Symposiums were huge successes and prompted articles in three special issues of 
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LETTERS TO THE EDITOR 


Tex, not PC Tex 

To the Editor: 

In the March issue of Computer, in 
a review of EXP (p. 88), Donald Cat- 
lin states 

The American Mathematical Society has 
decreed that submitted papers should be 
done in PC Tex, making it the standard 
in the mathematical world. How de¬ 
pressing! 

How depressing indeed, if it were 
true; fortunately, it is not! To restrict 
mathematicians who use Unix work¬ 
stations of VAXes or Macs to a pro¬ 
gram that is available only on a PC is 
neither friendly nor professional, and 
this would not be a policy acceptable 
to the AMS. 

The AMS does support the use of 
Tex as a coding and typesetting lan¬ 
guage for mathematics, uses Tex to 
produce its own publications, and en¬ 
courages mathematicians to submit 
manuscripts in AMS-Tex or AMS-La- 
tex. But it takes no position on which 
underlying software package an au¬ 
thor might use. AMS acts as a distrib¬ 
utor of a wide selection of packages to 
assist authors in setting up their own 
environment for writing mathematics 
in Tex. 

William B. Woolf 

American Mathematical Society 

“PC” should have been omitted in the 
quoted statement. We regret the error 
and appreciate the clarification. — Ed. 


Theory vs. practice 

In January, Computer published let¬ 
ters from two readers who were drop¬ 
ping their Computer Society member¬ 
ship. Both were dissatisfied with the 
focus of society periodicals — but for 
opposite reasons. One, a college pro¬ 
fessor, deplored the perceived shift 
from “issues relating to current re¬ 
search and college-level teaching” to 
articles aimed at “practitioners work¬ 
ing on software and hardware devel¬ 
opment.” The other, a practicing soft¬ 
ware engineer, found Computer “so 
focused on academic publication” that 
he had not seen a single article of in¬ 
terest during the past year. 

As the first reader put it, this di¬ 


chotomy may be “an inevitable effect 
of the attempt to broaden the mem¬ 
bership.” However, there should be an 
optimum mix of article type, focus, and 
length that will meet the needs of the 
majority of our readers. To try to find 
out what that mix is, we posed three 
questions in the January issue and 
asked you to respond via the reader 
service card. Unfortunately, the first 
question was poorly phrased and gave 
only two basic choices instead of the 
intended three. (This might indicate a 
staff bias.) The tally for each question 
is in the table below; selected com¬ 
ments from the cards appear below. 

To gain more information, the Com¬ 
puter Society recently contracted for a 
professionally conducted readership 
survey of three of its magazines and 
one transactions. And Computer has 
anticipated the desire for more and 
shorter articles — at least in its theme 
issues. For example, the May 1992 is¬ 
sue on computer architectures for in¬ 
telligent systems had 10 articles, four 
full-length articles and six short re¬ 
ports, as will the July 1992 issue on 
document image analysis systems. 

—Marilyn Potes, managing editor 

I strongly support your current for¬ 
mat/content and rely on you for de¬ 
tailed, groundbreaking articles. (I’m a 
business software developer.) 

—L.L., Midlothian, Va. 

Being an application computer engi¬ 
neer, I feel that I benefit from articles 
written for research and academia. Af¬ 


ter reading these articles, I ask myself 
how I can apply theory to actual work 
and implement it accordingly. I feel 
that researchers can do the same — 
apply “real life” concerns to their re¬ 
search. 

—M.F., New York, N.Y. 

Publications of IEEE and ACM are 
primary sources of material for the 
continuing education of computer 
professionals. Research results can be 
presented in such a way that they are 
accessible to people outside the im¬ 
mediate focus. Please emphasize this 
approach!! 

—J.L., East Lansing, Mich. 

I would like to see shorter articles 
with expanded information available 
by request. Therefore, more topics 
could be covered (introduced), and 
greater detail would be available to all 
who are interested. 

—S.C., Pikesville, Md. 

I am dropping my IEEE member¬ 
ship with some regrets. While I find 
IEEE Software to be fairly useful, I 
can no longer justify $142 per year to 
read six magazines. 

—B.H., Everett, Wash. 

Basically, you need to shift from an 
EE paradigm to computer science. 

—S.C., Bowie, Md. 

I keep looking for engineer-orient¬ 
ed material. This issue didn’t qualify. 

—P.C., Seattle, Wash. 


Response to questions published in January 1992 Letters to the Editor (153 replies 
received; totals exceed 100 percent because of multiple selections). 


Computer articles are 

Too research-oriented and theoretical for me 

76 

50% 

Just right 

48 

31% 

Not practical enough to have immediate value 

72 

47% 

The type of articles I prefer are 

Tutorials 

119 

78% 

Surveys 

74 

48% 

Detailed reports 

31 

20% 

The best article length is 

Short: Under seven pages with up to 10 articles per issue 

95 

62% 

Medium: Eight to 12 pages with six to eight articles per issue 

58 

38% 

Long: Over 12 pages with only five articles per issue 

7 

5% 
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ADVANCE PROGRAM FOR INTERNATIONAL CONFERENCE ON 
APPLICATION-SPECIFIC ARRAY PROCESSORS 
(ASAP'92) 

August 4 - 7 ,1992 - The Claremont Resort, Berkeley, California, USA 

This conference is the 6th of the series which began with the International Workshop on Systolic 
Arrays held in Oxford, England, in 1986. The expanded scope reflects the growing interest in 
application-specific computing. Themes emphasized include algorithms, software, architectures, 
design methods and performance evaluation of application-specific parallel computing systems. 
General Chair, J. Fortes; CoPragram Chairs, E. Lee; T. Meng; IVogram Committee, M. Bayoumi, B. 
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Rabaey, Y. Robert, J. Robinson, E. Swartzlander, M. Valero, K. Vissers, K. Yao; Local Arrangements, J. Beck 


Wednesday, August 5 

Opening Session 

Keynote Address; Special-Purpose vs. General-Purpose Parallel 

Computing, C. Leiserson, USA 

Session 1: Scheduling and Mapping I 

Partitioning of Processor Arrays: A Piecewise Regular Approach, J. 

Teich, L. Thiele, Germany; Hierarchical Scheduling of DSP Programs 

onto Multiprocessors for Maximum Throughput, P. Hoang, J. Rabaey, 

USA; Linear Scheduling is Close to Optimality, A. Darte, L. 

Khachiyan, Y. Robert, France; On Systolic Mapping of Multi-Stage 

Algorithms, Y-T. Hwang, Y. Hu, USA 

Session 2: Parallel Architecture 

On Cycle Borrowing Analyses for Interconnected Chips Driven by 
Clocks Having Different but Commensurable Speeds, G. Jennings, 
Sweden; On Partitioning of Multistage Algorithms and Design of 
Intermediate Memories, M. Sauer, E. Bernard, J. Nossek, Germany; A 
Reconfigurable Processor Array with Routing LSIs and General 
Purpose DSP's, J. Levison, I. Kuroda, T. Nishitani, Japan 
Session 3: Hardware Design Methodology 

Highlight Talk: Synthesis of Application-Specific Multiprocessor 
Systems Including Memory Components, S. Prakash, A. Parker, USA; 
An Integrated System for Rapid Prototyping of High Performance 
Algorithm Specific Data Paths, D. Chen, L. Guerra, E. Ng, M. 
Potkonjak, D. Schultz, J. Rabaey, USA; ARREST: An Interactive 
Graphic Design Tool for VLSI Arrays, W. Burleson, B. Jung, USA; 
Pipelining: Just Another Transformation, M. Potkonjak, USA 
Session 4: VLSI Architectures 

A VLIWlSIMD Microprocessor for Artificial Neural Network Compu- 
I tations, K. Asanovic, J. Beck, B. Kingsbury, P. Kohn, N. Morgan, J. 
Wawrzynek, USA; Implementing a Family of High Performance, Mi¬ 
crograined Architectures, R. Owens, M. Irwin, T. Kelliher, M. Vish- 
wanath, R. Bajwa, USA; Scalable Deterministic Boltzmann Machine 
VLSI Using Multi-Chip Modules, M. Murray, J. Burr, D. Stork, M-T. 
Leung, K. Boonyanit, A. Peterson, USA; Discrete Wavelet Transforms 
in VLSI, M. Vishwanath, R. Owens, USA; Algorithms and Archi¬ 
tectures for High Performance Recursive Filtering, S. McQuillan, J. 
McCanny, Ireland 
Panel Session: 

The Role of FPGAs in Application-Specific Computing 
Thursday, August 6 
Session 5: Special Session 

On Metrics of Super Performance, Y. Wu, US A, Wafer Scale Integration 
for Improved Signal Processor Efficiency, E. Swartzlander, Jr., USA; 
Some Low-Power Implementations of DSP Algorithms, B. Liu, USA; 
Wafer Scale Integration of Adaptive Antenna Processing, C. Rader, 


Session 6: Special Session (Cont.) 

Heterogeneous DSP Systems for Sonar, T. Curtis, England; Applica¬ 
tion of a Constant Capacity Signal Flow Architecture, H. Hatereder, 
USA; Application and Packaging of AT&T DSPS Parallel Signal Pro¬ 
cessor, R. Shively, L. Wu, USA; Architecture and Realization of a 
Multi Signal Processing System, A. Gunzinger, Switzerland 
Session 7: VLSI Architectures 

Highlight Talk: A Massively Parallel Computer for High Definition 
System Simulation, S. Knight, USA; High Speed Bit-Level Pipelined 
Architectures for Redundant CORD 1C Implementation, H. Dawid, H. 
Meyr, Germany; High-Speed VLSI Architectures for Soft-Output 
Viterbi Decoding, O. Joeressen, M. Vaupel, H. Meyr, Germany; An 
Architecture for Tree Search Based Vector Quantization for Single 
Chip Implementation, H. Park, V. Prasanna, C-L. Wang, USA; A 
Systolic Array Chip for Robot Inverse Dynamics Computation, M. 
Rahman, D. Meyer, USA; A Method to Synthesize Modular Systolic 
Arrays with Local Broadcast Facility, T. Risset, France 
Session 8: Poster Session 

A Systolic Rank Revealing QR Algorithm, F. Lorenzelli, K. Yao, T. 
Chan, P. Hansen, USA; Interval-Related Problems on Reconfigurable 
Meshes, S. Olariu, J. Schwing, J. Zhang, USA; A Parallel Sorting Al¬ 
gorithm on an Eight-Neighbor Processor Array, K. Tanno, T. Takeda, 
S. Horoguchi, Japan; Fault Tolerant Matrix Triangularization and So¬ 
lution of Linear Systems of Equations, P. Fitzpatrick and C. Murphy, 
Ireland; Systolic Architecture for Finite-State Vector Quantization, R. 
Kolagotla, S-S. Yu, J. Jaja, USA; Matrix Computation on Arrays of 
DSPs, J. Moreno, M. Medina, Chile; MAMACG: A Tool for Mapping 
Matrix Algorithms to Mesh Array Computational Graphs, M. Erce- 
govac, USA; Determining Longest Common Subsequences of Two 
Sequences on a Linear Array of Processors, A. Mukherjee, USA; Asso¬ 
ciative Information Processing: Algorithms and System, W. Poech- 
mueller, A. Koenig, M. Glesner, Germany; Parallel Architecture for a 
Pel-Recursive Motion Estimation Algorithm, E. Frimout, J. Driessen, 
E. Deprettere, Netherlands 

Friday, A ugust 7 
Session 9: Scheduling and Mapping 
Mapping Locally Recursive SFGs upon a Multiprocessor System in a 
Ring Network, W. Sung, S. Mitra, Korea; Transformation Techniques 
for Serial Array Design, W. Luk, England; Compilation of Narrowband 
Spectral Detection Systems for Linear MIMD Arrays, H. Printz, 

France; Programming Systolic Arrays, R. Hughey, USA; Scheduling 
Partitionings in Systolic Algorithm, A. Suarez, J. Llaberia, A. Fer¬ 
nandez, Spain 

Session 10: Design Methodology 

Optimal Design of Lower Dimensional Processor Arrays for Uniform 
Recurrences, K. Ganapathy, B. Wah, USA; Efficient Scheduling 
Methods for Partitioned Systolic Algorithms, P. Kuchibhotla, B. Rao, 
USA; Fully Static Multiprocessor Realization for Real-Time Recursive 
DSP Algorithms, Y. Hu, USA; High Level Software Synthesis for 
Signal Processing Systems, S. Ritz, M. Pankert, H. Meyr, Germany 
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The Many Faces 
of Consensus in 
Distributed 
Systems 


John Turek, IBM T.J. Watson Research Center 
Dennis Shasha, New York University 


Many distributed 
computing protocols 
require the ability to 
achieve consensus 
among processors. A 
parable of human 
communication starts 
this survey of the 
(im)possibilities. 


B ob and Alice have discovered that they have a lot in common. For 
example, they both prefer e-mail to the telephone. On a cold winter day, 

Alice sends Bob electronic mail at 10 a.m., saying, “Let’s meet at noon in 
front of La Tryste.” 

The e-mail connection between our two protagonists is known to lose messages, 
but today they are lucky and Alice’s message arrives at Bob’s workstation at 10:20 
a.m. Bob looks at his calendar and sees that he is free for lunch. So he sends an 
acknowledgment. 

Alice receives the acknowledgment at 10:45 a.m. and prepares to go out, when 
a thought occurs to her: “If Bob doesn’t know that I received his acknowledgment, 
he might think I won’t wait for him. I’d better acknowledge his acknowledgment.” 

And so it goes. We can show that, ultimately, neither Bob nor Alice will make 
it to La Tryste unless at least one of them is willing to risk waiting in the cold 
without meeting the other. j 


“The Parable of La Tryste” and the consensus 
problem 


This parable holds several lessons for designers of distributed systems. 

• Easier problem lesson. If the problem was simply that Alice wanted to be sure 
Bob received her original message, then the first acknowledgment would have 
sufficed. The issue is that Bob is not sure Alice knows that the first message arrived. 
Thus, the problem of transmission is easier than this problem of mutually coordi¬ 
nated action. 

• Reliable network lesson. A phone call appears to solve the problem: 
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Alice : Let’s meet at noon. 

Bob: Sure, see you then. 

The basis of this solution is the assump¬ 
tion that one party will hear what the 
other says within a bounded delay or 
that the existence of a problem will be 
evident within a bounded delay. If this 
assumption breaks down, either Bob or 
Alice might get stuck waiting out in the 
cold. 

•Probability lesson. Imagine that 
Alice and Bob each send a flurry of 
duplicate messages instead of a single 
message each time. They might act on 
the assumption that at least one mes¬ 
sage will arrive. If they were right with 
probability p for each flurry, then a two- 
message protocol would succeed with 
probability p 2 . Here, success means that 
neither would wait in the cold and they 
would lunch together at La Tryste. 

The price of failure is higher in many 
applications. For example, if air traffic 
controllers used computers subject to 
these kinds of faults, we would be much 
more reluctant to use the airlines. For 
this reason, the probabilistic approach¬ 
es cited in the literature on consensus 
eschew such risks. These approaches 
ensure that a decision will be made within 
a bounded amount of time with high 
probability. However, they insist that if 
a decision is eventually reached, it will 
be correct. 

Consenting adults. In the consensus 
problem, a set of agents must all agree 
on a decision based on their initial states. 
Typically, only two decisions are allowed, 
0 and 1. (Once a protocol for two deci¬ 
sions is available it can be extended to 
any number of decisions.) The numbers 
may represent actions. For example, 1 
may represent “commit” and 0 may rep¬ 
resent “abort” in a distributed database 
system. The agents must all output the 
same value and there must be some 
initial state for which 0 is the output and 
another for which 1 is the output. 

Formally, a consensus protocol is cor¬ 
rect if it meets the following conditions: 

• Consistency. All agents agree on the 
same value and all decisions are final. 

• Validity. The agreed-upon value 
must have been some agent’s input. 

• Termination. Each agent decides on 
a value within a finite number of steps. 

In our parable, the consistency condi¬ 
tion would be violated if it was possible 
for either Bob or Alice to wait outside 


in the cold alone. The validity condition 
would be violated if both Bob and Alice 
wanted to meet at La Tryste, but nei¬ 
ther of them went. (This condition rules 
out the consistent but uninteresting so¬ 
lution where everyone always decides 
the same thing — for example, “Don’t 
meet.”) The termination condition would 
be violated if they were never to agree. 

The right time and place. A promi¬ 
nent application of consensus is in com¬ 
mit protocols for distributed databases. 
In such protocols, all server sites must 
agree whether to commit or abort, and 
if any site wants to abort, then all sites 
must abort. The commit problem is strict¬ 
ly harder to solve than the consensus 
problem because of this priority in fa¬ 
vor of aborts. Therefore, any result in¬ 
dicating the impossibility of consensus 
translates to an impossibility result for 
the commit problem. 

A second important application area 
for consensus is ordered atomic broad¬ 
cast protocols. Such protocols try to 
guarantee that if two messages, m and 
m, are sent, then either every working 
site will receive m first or every working 
site will receive m first. As we will show, 
any system that can implement ordered 
atomic broadcast can also achieve con¬ 
sensus. Consequently, whenever con¬ 
sensus is impossible, so is ordered atomic 
broadcast. 

In fact, consensus is part of any dis¬ 
tributed system that embodies coordi¬ 
nated activity — from the synchroniza¬ 
tion of clocks, to the election of leaders, 
to the coordination of rocket firings. 1 

Moreover, consensus is closely relat¬ 
ed to fault tolerance. A system is syn¬ 
chronous if all processors proceed at 
predictable speeds. Otherwise, the sys¬ 
tem is asynchronous. A protocol is wait- 
free if no processor can indefinitely block 
the progress of any other processor. 
Herlihy 2 among others has shown that 
in an environment where n processors 
operate asynchronously, the ability to 
reach consensus among all the proces¬ 
sors is a necessary condition for wait- 
free implementations of many shared- 
data structures and a sufficient condition 
for wait-free implementations of any 
shared-data structure. In other words, 
any asynchronous distributed system for 
which data sharing is important must be 
capable of consensus if it is to tolerate 
certain kinds of failures. 

Because consensus is fundamental to 
so many distnBtrt^cTbperations, its so¬ 


lution provides a fundamental building 
block to system designers. 

“... begotten by despair upon impos¬ 
sibility.”* Consensus can be easy or dif¬ 
ficult to achieve depending on the kind 
of computer system (synchronous or 
asynchronous) and the failure assump¬ 
tions. In a famous paper, Fischer, Lynch, 
and Paterson 3 showed the impossibility 
of deterministic consensus among two 
or more processors in an asynchronous 
distributed system. Since then, the con¬ 
sensus problem has been examined un¬ 
der many different synchrony and fail¬ 
ure assumptions. For example, Fischer, 
Lynch, and Merritt 4 showed that con¬ 
sensus cannot be achieved in a synchro¬ 
nous environment if even one third of 
the processors are “maliciously” faulty 
— that is, if they act in a way that simu¬ 
lates an agent that tries to make the 
other processors make inconsistent de¬ 
cisions. 

Given the role of consensus as a build¬ 
ing block, these assumptions ha ve a large 
impact on what can be achieved in prac¬ 
tice. In this article, we survey known 
results regarding consensus, relating 
them to practice and explaining the small 
collection of elegant ideas embodied in 
their proofs. Our goal is to give practi¬ 
tioners some sense of the system hard¬ 
ware and software guarantees that are 
required to achieve a given level of reli¬ 
ability and performance. Our survey 
focuses on two categories of failures: 

• Fail-stop failures. These occur when 
processors fail by stopping. While this is 
not a problem when processors are syn¬ 
chronous, the combination of asynchro¬ 
ny and fail-stop failures can make con¬ 
sensus impossible. We discuss these 
failures in the following section, “Hesi¬ 
tate and you’re lost.” 

• Byzantine failures. These occur when 
processors fail by acting maliciously. 
This is a useful, though pessimistic, 
model of software failures. Depending 
on the number of failures in the system, 
consensus may be impossible under 
Byzantine failures even when the sys¬ 
tem is synchronous. We discuss these 
failures in the section titled “Plotting a 
Byzantine agreement.” 


*Andrew Marvell, “The Definition of Love,” 
The Poems of Andrew Marvell , Hugh MacDonald, 
ed., Harvard Univ. Press, Cambridge, Mass., 1952, 
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Hesitate and you’re lost 

A distributed system is made up of 
processors communicating through a 
shared communications medium, as il¬ 
lustrated in Figure 1. Sometimes we can 
assume that the communications media 
are reliable (for example, in backplane 
networks). Sometimes we can assume 
that processors are reliable (for exam¬ 
ple, in quadruple redundant hardware 
configurations). Suppose a given dis¬ 
tributed system must solve problems at 
least as difficult as consensus. This would 
be true, for example, if the system was 
to include a distributed database. The 
designer should know how reliable the 
components must be in order to solve 
the consensus problem. 

This section looks at how synchrony 
affects the spectrum of possibilities. 

A world of (im)possibilities. Let’s 
return to our original scenario where 
Bob and Alice are sending each other 
messages across a computer network. 
The difficulty in this scenario is that 
network delay has no bounds and mes¬ 
sages can get lost. We observed that 
consensus is impossible under these con¬ 
straints. Let’s strengthen the network 
so that messages are never lost though 
they can still be delayed, and let’s add 
the condition that either Bob or Alice 
could be fired at any time. Since the 
network never fails, Alice could send 
Bob a message and then wait for his 
response. But if Bob gets fired before 
he receives Alice’s message, Alice may 
end up waiting indefinitely. Under these 
conditions, is consensus possible? 

Fischer, Lynch, and Paterson 3 showed 
the surprising result that in a distribut¬ 
ed system with an unbounded but finite 
message delay, there is no protocol that 



Figure 1. A distributed system. 


can guarantee consensus within a finite 
amount of time if even a single proces¬ 
sor can fail by stopping. This result im¬ 
plies no possibility of consensus for Bob 
and Alice under the redefined circum¬ 
stances. (The reasoning behind this is 
discussed later under the subhead “Prov¬ 
ing the impossible.”) 

While Fischer, Lynch, and Paterson’s 
result shows that a completely asyn¬ 
chronous system cannot guarantee con¬ 
sensus, it does not give much sense of 
what can be achieved in practice. More 
optimistic assumptions on the timing 
constraints within the network and 
among processors can yield consensus 
protocols, even in the presence of mul¬ 
tiple failures. Dolev, Dwork, and Stock- 
meyer 5 addressed this issue by identify¬ 
ing a set of system parameters for 
classifying asynchronous systems. The 
following items formally define a subset 
of those parameters: 

•Processors can be either synchro¬ 
nous or asynchronous. Processors are 
synchronous if and only if there exists a 
constant s > 1 such that for every s + 1 
steps taken by any processor, every oth¬ 
er processor will have taken at least one 
step. 

• Communication delay can be either 
bounded or unbounded. Delay is bound¬ 
ed if and only if every message sent by a 


processor arrives at its destination within 
t real-time steps, for some predeter¬ 
mined t. 

•Messages can be either ordered or 
unordered. Messages are ordered if and 
only if processor P r receives message m, 
before message m 2 when Pj sends m, to 
P, at real time t,, P 2 sends m 2 to P r at real 
time t 2 , and t, < t 2 . (For ordered atomic 
broadcasts, as described earlier in “The 
right time and place”and used below in 
case 2, the slightly weaker condition 
that either all sites either receive m 
before m or all sites receive m before m 
will suffice.) 

• Transmission mechanism can be ei¬ 
ther point-to-point or broadcast. The 
transmission mechanism is point-to- 
point if a processor can send a message 
in an atomic step to at most one other 
processor. It is broadcast if a processor 
can send a message to all the processors 
in an atomic step. 

Table 1 summarizes the possibilities for 
consensus presented by Dolev, Dwork, 
and Stockmeyer. In the system Fischer, 
Lynch, and Paterson studied, messages 
were unordered, communication was 
unbounded, and processors were asyn¬ 
chronous. As the table shows, consen¬ 
sus is impossible under these conditions. 
It is possible, however, in three minimal 
cases: 

• Case 1. Processors are synchronous 
and communication is bounded. 

• Case 2. Messages are ordered and 
the transmission mechanism is broad¬ 
cast. 

• Case 3. Processors are synchronous 
and messages are ordered. 

We have included the third case for 
completeness. However, the best known 
algorithm for achieving consensus in 
this case requires an exponential num¬ 
ber of messages and is therefore of little 
practical interest. 

Case 1 describes the situation in which 
every processor can use time-outs to 
tell if another has failed. This assump¬ 
tion is the basis of the standard commit 
protocols that work under the fail-stop 
assumption, such as three-phase com¬ 
mit. 6 

Case 2 describes a situation in which 
processors can be asynchronous and 
some of them can also fail. However, 
they have an ordered atomic broadcast 
primitive (perhaps because they share a 


Table 1. Conditions under which consensus is possible. 
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reliable bus). To achieve consensus, each 
processor broadcasts its initial value to 
all other processors. The processors then 
read messages from the network and 
note the first value received. Since mes¬ 
sages are ordered, all the processors 
will agree as to which was the first value 
placed on the network. 

A variation of case 2 is k-casting. This 
variation assumes that the transmission 
mechanism allows broadcast to at most 
k other processors. Dolev, Dwork, and 
Stockmeyer show that if k-casting is 
possible and messages are ordered, the 
system can achieve deterministic con¬ 
sensus in the presence of up to k - 1 
failures. 

Another variant assumes that pro¬ 
cessors are “nearly” synchronous. If a 
processor can read, process, and write 
to the network in one atomic step, the 
addition of bounded communication 
delay and broadcast transmission will 
be sufficient for achieving consensus. 
The idea is that if processors can exe¬ 
cute a critical section of code within a 
predictable amount of time, then the 
problems associated with processor asyn¬ 
chrony can be overcome. This can often 
be achieved in practice by having pro¬ 
cessors disable interrupts during the 
critical code section. 

Agreeing on shared memory. Does 
consensus become easier to implement 
in a system with a reliable shared mem¬ 
ory? Intuition might suggest that the 
inherent broadcast capabilities and re¬ 
liability of shared memory could suf¬ 
fice for consensus. While this is true for 
the Byzantine failures in synchronous 
systems that we will discuss later, it is 
not the case for asynchronous systems. 

Herlihy 2 showed the impossibility of 
consensus in a distributed system with 
asynchronous processors and a shared 
memory that supports only reads and 
writes. Achieving consensus requires 
adding synchronization primitives to the 
shared memory. In fact, Herlihy showed 
the existence of a hierarchy of increas¬ 
ingly more powerful synchronization 
primitives that allow processors to 
achieve consensus in the presence of 
increasingly many faults. 

To understand why shared memory is 
not enough, recall the minimum condi¬ 
tions presented by Dolev, Dwork, and 
Stockmeyer. Shared memory with read 
and write provides the equivalent of a 
broadcast mechanism, but does not of¬ 
fer the equivalent of ordered messages. 


fetch&add(m, v) 
begin /* Atomic action*/ 
oldm <— m 

return (oldm)\ 
end; /*Atomic action*/ 


Figure 2. Fetch&add (consensus num¬ 
ber = 2). 


compare&swap(m, new, old) 
begin /*Atomic action*/ 
if (m = old) then 
begin 

return (true) 
end 

else return (false ); 
end; /*Atomic action*/ 


Figure 3. Compare&swap (consensus 
number = n). 


Once two processors have written their 
messages to the shared memory, there 
is no way for a third processor to deter¬ 
mine which one wrote its message first. 
Actually, because of the asynchronous 
nature of the processors, even two writ-^ 
ing processors can’t agree which wrote 
its message first. 

Given an asynchronous shared-mem¬ 
ory system prone to fail-stop failures, 
Herlihy defines the consensus number 
of a synchronization primitive. A prim¬ 
itive with a consensus number n can 
achieve consensus among an arbitrary 
number of processors even if up to n -1 
processors stop. By definition, a primi¬ 
tive with a consensus number n - 1 , but 
not n, cannot simulate a primitive with 
a consensus number n (otherwise, it too 
would have consensus number n). Con¬ 
versely, a primitive with consensus num¬ 
ber n can simulate a primitive with con¬ 
sensus number n - 1. 

For example, atomic read and write 
operations have a consensus number of 
1, but not 2. Therefore, in a shared 
memory allowing only reads and writes, 
no deterministic algorithm can achieve 
consensus among two or more proces¬ 
sors even if only one of the processors is 
allowed to fail. 

Figure 2 presents fetch&add, a prim¬ 
itive that reads and increments a loca¬ 
tion from memory in one atomic step. 
Fetch&add has a consensus number of 


2, but not 3. Therefore, adding it or a 
variant to the shared memory pushes 
the impossibility result out to three or 
more processors in the presence of two 
or more failures. 

The notion of a universal primitive is 
important. Such a primitive has a con¬ 
sensus number of n for arbitrary n (that 
is, all but one of the processors can stop 
and consensus will still be reached). Fig¬ 
ure 3 shows a universal primitive called 
compare&swap. It replaces the value in 
memory location m with new if and only 
if the old value in memory is equal to 
old. It is not difficult to see that 
compare&swap is universal. Assume 
that a specified memory location, m, 
has an initial value of _L. Each proces¬ 
sor, P„ proceeds as follows: 

(1) Write initial value to location a[i\. 

(2) Compare&swap(v, _L, i). (That 
is, attempt to replace the 1 in location 
v with the processor ID.) 

(3) Decide a[v]. 

Only one processor, P, will succeed with 
the compare&swap. All processors will 
decide on the value that P places in v. 

Herlihy’s work shows that the 
compare&swap is a more power ful syn- 
chronizatio n primitive for achieving 
consensus than are the test&set and 
the fetch&add, thereby dispelling a 
popular myth on the relative power of 
the latter two primitives. Of course, this 
does not preclude their usefulness; tech¬ 
niques such as combining can make them 
more efficient than compare&swap. It 
just turns out that there are certain things 
they cannot do. 

Recall that a wait-free protocol is one 
in which no processor can be held up 
indefinitely by the actions, or failures, 
of other processors. Since consensus in 
the presence of an arbitrary number of 
failures cannot be achieved without us¬ 
ing a universal primitive, it follows that 
there are computations that cannot be 
performed in a wait-free manner in a 
distributed system without a universal 
primitive. Herlihy showed that in the 
presence of a universal primitive, any 
computation can be performed in a wait- 
free fashion. Thus, the ability to achieve 
consensus is necessary for any general- 
purpose distributed system that pur¬ 
ports to tolerate failures. 

Proving the impossible. Here we de¬ 
scribe the proof of Fischer, Lynch, and 
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Paterson’s impossibility result. 3 Name¬ 
ly, in a completely asynchronous mes¬ 
sage-passing system (that is, one in which 
messages have unbounded but finite 
transit times), no deterministic consen¬ 
sus protocol can tolerate even a single 
processor failure. 

The state of a system, denoted a con¬ 
figuration, is defined by the messages 
that have not yet been delivered to their 
destinations and the individual states 
(that is, program counter and internal 
memory) of the individual processors. 
If at some point in the computation 
either 0 or 1 can still' be reached, the 
system is said to be in a bivalent state. 
Otherwise, the system is said to be in a 
univalent state. We say the system is 0- 
valent if 0 has been decided and 1 -valent 
if 1 has been decided. 

An event, e, is defined as the receipt 
of a message, m, by a processor. For the 
sake of generality, m may be an empty 
message. Since we assume the protocol 
is deterministic, the processors can be 
said to make decisions only when an 
event occurs. A sequence, or subse¬ 
quence, of events is called a schedule. 
The proof shows that an adversary can 
keep the protocol going forever by slow¬ 
ing processors down or killing a single 
processor. Specifically, the following two 
lemmas prove the theorem: 

•Lemma 1. There exists an initial 
configuration that is bivalent. 

• Lemma 2. Given a bivalent configu¬ 
ration, there exists a nonempty sched¬ 
ule leading to another bivalent configu¬ 
ration. 

Lemma 1 is best described by a vari¬ 
ation on the bald man’s paradox. A man 
with a full head of hair is not bald. A 
man with little or no hair is bald. A man 
can be either bald or not bald (for exam¬ 
ple, if he has 1,000 or more hairs, he is 
not bald; otherwise, he is bald). If we 
removed each hair one at a time from a 
man with a full head of hair, then we will 
reach a point where pulling one more 
hair will cause us to change our descrip¬ 
tion of him. However, if he was wearing 
a hat and only, say, 999 strands of his 
hair were showing, it would be impossi¬ 
ble to determine whether he was bald or 
not bald. 

If all processors start with an initial 
value of 0, then the system must decide 
0 to satisfy the validity condition on 
consensus. Likewise, if all processors 
start with an initial value of 1, then the 



Figure 4. Initial inputs to processors 
and the resulting decisions. 



another. 


system should decide 1. As shown in 
Figure 4, it is possible to go from a 
configuration in which all processors 
start with an input value of 0 to a config¬ 
uration in which all processors start with 
an input value of 1 by flipping each 
processor’s input value one at a time. 
Assume that there is no initial bivalent 
state. As with the bald man’s paradox, 
there must be a single processor where¬ 
by flipping that input bit shifts the deci¬ 
sion from a 0 to a 1. If an adversary 
caused the processor corresponding to 
that bit to fail before the protocol even 
began, then the two configurations would 
be impossible to distinguish from each 
other and would reach the same deci¬ 
sion. This contradicts the assumption 
that one configuration could only have 
yielded a 0 and the other a 1. 

To prove lemma 2, assume that the 
system is currently in a bivalent config¬ 
uration, C. If a schedule exists that takes 
the system to another bivalent configu¬ 


ration, then we are done. Otherwise, 
since the system was in a bivalent con¬ 
figuration, there exist at least two events, 
e and e, whereby e takes the system to a 
0-valent configuration D, and e takes 
the system to a 1-valent configuration 
D (see Figure 5). No events lead to 
another bivalent state. Call e and e the 
deciding events. There are two cases: 

• Deciding events e and e' occur on 
different processors. Since events de¬ 
note message receptions, applying e and 
e in either order yields the same config¬ 
uration F. By assumption, if e is applied 
first, then F is 0-valent. If e is applied 
first, then F is 1-valent. This is clearly 
absurd. Hence, in a deterministic con¬ 
sensus protocol, any pair of deciding 
events yielding different valences must 
occur on the same processor. 

• Deciding events e and e' both occur 
on some processor P. If e occurs first and 
then P fails, the resulting configuration 
should be 0-valent. If e occurs first and 
then P fails, the resulting configuration 
should be 1-valent. But there is no per¬ 
ceivable difference between these con¬ 
figurations. Again, we get a contradic¬ 
tion. 

Since an initial bivalent state exists and 
the adversary can keep the system in a 
bivalent state for an arbitrary period, 
there is no way of guaranteeing consen¬ 
sus in an asynchronous distributed sys¬ 
tem in which one processor can fail. 

A different approach to understand¬ 
ing the issues and difficulties of the con¬ 
sensus problem uses a formalism called 
knowledge logic. A good reference to 
knowledge logic is the set of ACM con¬ 
ference proceedings from 1986 and 1988 
entitled Theoretical Aspects of Reason¬ 
ing About Knowledge. 

Sharing messages. Herlihy proved 
that asynchronous processors, commu¬ 
nicating via a shared memory, cannot 
achieve deterministic consensus in the 
presence of one faulty processor. He 
used a technique similar to the one used 
by Fischer, Lynch, and Paterson. Here, 
we relate the two results using a differ¬ 
ent kind of glue. 

Even though consensus cannot be 
achieved in an asynchronous message¬ 
passing environment with faults or in an 
asynchronous shared-memory environ¬ 
ment with faults, it would still seem that 
shared memory provides a more power¬ 
ful primitive than message passing. In 
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one sense, this is true. Shared-memory 
systems can solve some problems even 
if a majority of the processors fail — 
problems that cannot be solved in a 
message-passing environment under the 
same conditions. 

But what if fewer than half of the 
processors are allowed to fail? Attiya, 
Bar-Noy, and Dolev 7 have shown that 
under these circumstances the message¬ 
passing system of Fischer, Lynch, and 
Paterson can reliably emulate a shared- 
memory environment. This immediate¬ 
ly lets us apply results from the Fisher, 
Lynch, and Paterson message-passing 
model to the read-write shared-memo¬ 
ry model. Thus, the Fischer, Lynch, and 
Paterson impossibility result implies 
Herlihy’s result and shows the impossi¬ 
bility of achieving consensus in the pres¬ 
ence of even one fault in an asynchro¬ 
nous, read-write, shared-memory 
system. 

One failure too many. The emulation 
result also provides an easier frame¬ 
work for implementing protocols in asyn¬ 
chronous message-passing systems, but 
before we show how to implement a 
shared memory, we will briefly discuss 
what we expect from a shared memory 
and why we cannot reliably emulate 
shared memory in a message-passing 
system in which a majority of the pro¬ 
cessors are allowed to fail. 

To tolerate k failures, a system must 
maintain at least one copy of an object 
at k +1 different processors. Otherwise, 
the k failures could occur at the proces¬ 
sors containing the copies of the object, 
and the object’s value would be lost. 
However, maintaining at least one copy 
does not solve all our problems. Since 
the processors holding the copies may 
be slow to respond, two processors (or 
even the same processor) reading a copy 
of an object might not be reading the 
same copy. The fact that a 
writer may not have complet¬ 
ed its write operation means 
that the later of two read op¬ 
erations may actually access 
an “earlier” version of the ob¬ 
ject. This leads to inconsis¬ 
tent executions. 

The correctness criterion 
that we expect from a shared 
memory is the ability to im¬ 
plement shared atomic regis¬ 
ters. An atomic register satis¬ 
fies the following property: If 
processor P, finishes access¬ 


ing the register before processor P 2 be¬ 
gins accessing the register and one of 
the accesses is a write, then P 2 reads or 
writes a “later” version than P,. Specif¬ 
ically, assume that each value written 
into the register has a unique version 
number, then P 2 will see (write) a ver¬ 
sion number that is equal to or greater 
than that seen (written) by P,. 

To see why no algorithm could toler¬ 
ate even half of the processors failing, 
consider a scenario in which the proces¬ 
sors are partitioned into two groups of 
exactly equal size. Messages from one 
group to the other are “slow” while 
messages within each of the groups pro¬ 
ceed at predictable rates. Given this 
scenario, processors in one group can¬ 
not distinguish between the situations 
in which all the processors in the other 
group are being slow or have failed. If 
the protocol assumes that the proces¬ 
sors are slow, an adversary could cause 
the processors in the other group to fail. 
The protocol would not terminate and 
therefore would not be correct. If the 
protocol assumes that the processors in 
the other group have failed, then the 
two groups could come to different de¬ 
cisions, thus violating the consistency of 
the shared memory. 

Two majorities always intersect. The 
critical problem in the previous subsec¬ 
tion is that if the network can partition 
the set of processors, then two indepen¬ 
dent system components can proceed 
independently. Gifford 8 captured this 
observation in 1979 when he presented 
the idea of a quorum consensus. His 
algorithm shows how to reliably main¬ 
tain several replicas of a data item in a 
synchronous distributed system prone 
only to fail-stop failures. 

The idea is to make m copies of a data 
object A, {A,, X 2 , . . . , X m \. Writing 
proceeds by writing w > k copies of X. 


where k is the number of failures that 
can be tolerated. This set of writes is 
called a write quorum. Reading pro¬ 
ceeds by reading r copies of X. This set 
of reads is called a read quorum. The 
sum of the read and write quorums, w + 
r, must be greater than m to ensure an 
intersection between every pair of reads 
and writes. 

Attiya, Bar-Noy, and Dolev 7 used this 
idea to show how to emulate a reliable 
shared memory in an asynchronous 
message-passing system in which fewer 
than half the processors can fail. To 
illustrate the algorithm, we first give an 
algorithm to emulate shared memory in 
a synchronous message-passing system. 
Associated with each copy is a version 
number. At any point in time, the copy 
(or copies) with the largest version num¬ 
ber defines the current version. A read 
is executed as follows: 

(1) Retrieve a read quorum of X. 

(2) Select the copy with the largest 
version number. 

A write is executed as follows: 

(1) Retrieve the currently largest ver¬ 
sion number using the read procedure. 

(2) Increment the version number. 

(3) Send the new value along with the 
new version number to a write quorum. 

The processors receiving the new value 
will replace the “old” value in their 
local memory if and only if the version 
number of the new value is larger than 
the version number of the old value. 

Some care must be taken if multiple 
writers are allowed. To avoid confu¬ 
sion, all writers must write unique ver¬ 
sion numbers. We can guarantee this by 
concatenating the version number with 
the writing processor’s ID. 

While this algorithm for emulating 
the reading and writing of 
shared "memory works well 
synchronous system, it 
will not work in an asynchro¬ 
nous system. The primary dif¬ 
ficulty is the impossibility of 
guaranteeing that the copies 
will be read in the correct 
order. Figure 6 shows one 
such situation. There are 
three replicas — X x , X 2 , X, 
— of an object, X. A writer, 
W lt could succeed in writing 
to X , before slowing down. 

A subsequent reader, R u 
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Figure 6. Example showing how quorums can fail in asyn¬ 
chronous environments. 
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randcon(in) 
begin 
if in = 1 

globalcount <- globalcount + 1; 
else 

globalcount <- globalcount - 1; 
while -n < globalcount < n 
begin 

if globalcount < 0 
globalcount <— globalcount - 1; 
else if globalcount > 0 
globalcount <- globalcount + 1; 
else 

begin /* Atomic action*/ 
if flipO = 1 

globalcount <- globalcount + 1; 
else 

globalcount<— globalcount - 1; 
end; /*Atomic action*/ 
end; 

if globalcount > 0 decide(l); 
else decide(O); 
end; 


Figure 7. Simplified algorithm for randomized consensus. 
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Figure 8. Regions for coin tosses in randomized consensus. 


might read a quorum contain¬ 
ing X t and X 3 , thereby get¬ 
ting the new version of X 
written by W,. Later, another 
reader, R 2 , might read a quo¬ 
rum consisting of X 2 and X 3 . 

This quorum does not con¬ 
tain the new version of X. R 2 
therefore gets an earlier ver¬ 
sion than /?,, violating the con¬ 
ditions required for atomic 
registers. 

Attiya, Bar-Noy, and Dolev 
get around this problem us¬ 
ing a technique that turns out 
to be quite powerful in de¬ 
signing protocols for asyn¬ 
chronous distributed sys¬ 
tems: altruism. Rather than 
being greedy and trying to 
complete its own operation 
as quickly as possible, each 
process acts altruistically. If 
it sees that some other pro¬ 
cess may not have completed 
its operation, it takes time 
out to help the process com¬ 
plete. In this case, the read¬ 
ers help the writer. When a 
reader reads a quorum and 
realizes that the writer did 
not finish its job, the reader 
plays the role of the writer 
and writes a quorum with the 
current value and version 
number. For this approach 
to tolerate k failures, the read 
and write quorum sizes will 
each be at least k + 1, and the system 
must have at least 2k + 1 processors. 

Foiling your adversary. We have al¬ 
ready seen that deterministic consensus 
cannot be achieved in an asynchronous 
system in which even one processor is 
allowed to fail. Here we show that prob¬ 
ability provides a powerful tool in this 
context. Each processor is allowed to 
flip a coin. The adversary cannot affect 
the result of this random coin toss, but 
in all other ways it remains unaffected. 
For example, it can still slow down pro¬ 
cessors at will. The algorithm we present 
guarantees both validity and consisten¬ 
cy upon termination. Therefore, the ad¬ 
versary can only affect when the final 
decision is reached — not its correct¬ 
ness. 

To simplify presentation, we show an 
algorithm from Aspnes 9 that works in 
shared memory. From the previous 
section, we know that any such algo¬ 


rithm can be converted into an algo¬ 
rithm that will function in a message¬ 
passing system. The algorithm takes its 
inspiration from a one-dimensional 
random walk, which brings us back to 
Bob and Alice. 

Unable to agree on a meeting time 
with Alice, Bob consoles himself by going 
out drinking. He becomes intoxicated. 
His house lies at the end of the road on 
which the bar is located. Alice’s house is 
about the same distance in the other 
direction. He is undecided whether to 
go home and sleep or go to Alice’s house 
and chat. Assume that every time he 
takes a step he will stagger in the direc¬ 
tion of his house or Alice’s house with 
equal probability. If both houses lie n 
steps from the bar, how many steps will 
Bob take before reaching one of the two 
possible destinations? 

The answer is on the order of n 2 (de¬ 
noted 0(n 2 )). The walk provides us with 
the basis of the randomized consensus 


algorithm. Assume that pro¬ 
cessors can flip a coin and 
either add or subtract 1 from 
a global counter in one atomic 
step. Under this condition, 
Figure 7 shows the basic al¬ 
gorithm for randomized con¬ 
sensus on n processors. 

Since the adversary has no 
control over the coin flips 
(or the order in which they 
are added to the global 
counter), the time required 
to hit one of the absorbing 
boundaries at either n or -n 
corresponds to Bob’s random 
walk. Once one of the bound¬ 
aries has been reached, the 
remaining processors will 
eventually make the same 
decision. 

To make the algorithm 
work even when it is not pos¬ 
sible to flip a coin and incre¬ 
ment the counter in one 
atomic step requires extend¬ 
ing the region in which a coin 
can be flipped. Figure 8 shows 
these regions. 

The proposed adversary is 
more powerful than what one 
would encounter in practice. 
In fact, the adversary will not 
maliciously adj ust the speeds 
of processors. Rather, the 
speeds will be affected ran¬ 
domly. Aspnes and Herlihy 10 
give an algorithm with the 
same running time as the algorithm in 
Figure 7, but theirs uses a weakly biased 
coin that will land on the same side at all 
the processors with high probability. 
Since the correctness of that algorithm 
is not particularly intuitive, we omit the 
details. In practice, the biased coin can 
be replaced by a shared table of “ran¬ 
dom” coin flips that the processors read 
to get the (th coin flip. With a failure 
model in which delays occur randomly, 
this modification to their consensus pro¬ 
tocol yields an 0(n) algorithm. 

Plotting a Byzantine 
agreement 

Bob, Alice, and Joan are trying to get 
together for lunch. To simplify commu¬ 
nication, they have decided to use a 
reliable medium — the telephone. Con¬ 
ference calling is not available, so at any 
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one time Bob can talk with either Alice 
or Joan, but not both. Mistrust and in¬ 
sincerity abound; however, at most one 
member of the trio is truly malicious 
(we do not know which one) and trying 
to make one of the other two wait in the 
snow. 

Is there some protocol that the three 
can adopt such that (1) the two honest 
individuals will agree on whether or not 
to meet; (2) if all honest ones want to 
meet, then they will meet; and (3) if no 
honest ones want to meet, then they 
won’t meet? 

This problem is equivalent to the 
Byzantine generals problem studied by 
Lamport, Shostak, and Pease. 11 In their 
parable, several divisions of the Byzan¬ 
tine army are posted outside an enemy 
camp. Each division, headed by its own 
general, is trying to decide whether or 
not to attack the enemy camp. Howev¬ 
er, some of the generals are traitors and 
will try to keep the honest generals from 
reaching an agreement. A Byzantine 
failure is one in which a processor be¬ 
comes traitorous and acts maliciously. 
The problem of reaching cons ensus in a 
distributed system prone to Byzantin e 
failures is know n as^Byzantine^agr ee- 
ment. * ~~ ' ' ' 1 

^'—Byzantine failures were originally used 
to model hardware failures (or inher¬ 
ent flakiness) in avionics sensors, but 
they can also model software failures. If 
the software fails, we have no idea what 
it might do. Since it could do anything, 
the only fully general assumption to 
make is that it will do the worst thing 
possible. For it to do that, we 
assume that it is omniscient 
with respect to the state of 
the other (honest) processors. 

This section discusses the 
conditions under which a 
synchronous distributed sys¬ 
tem can tolerate Byzantine 
failures. 

Avoiding traitors. Given a 
synchronous message-passing 
system, is it possible to reach 
consensus in the presence of 
Byzantine failures? To an¬ 
swer this question, we need ‘ 
to be more specific regarding 
what the processors can do. 

If Bob, Alice, and Joan 
were to make a conference 
call, then all three would hear 
the same message and it 
would be impossible for the 



traitor to lie to one person and not the 
other. Thus, Byzantine failures are not 
a problem under a communication me¬ 
dium that “broadcasts” messages to all 
the processors. Therefore, because of 
the inherent broadcast capabilities of 
shared memory, Byzantine failures do 
not constitute a serious problem in that 
environment. (The ability to verify the 
authenticity of messages partially simu¬ 
lates this broadcast ability and is dis¬ 
cussed later under “Sign on the dotted 
line.”) 

When authentication is not available, 
Lamport, Shostak, and Pease show that 
Byzantine agreement is possible if and 
only if there are at least 3k + 1 proces¬ 
sors when k of the processors can fail. In 
other words, if one third or more of the 
processors are malicious, no determin¬ 
istic algorithm can guarantee consensus 
among the honest processors. (We give 
their proof of this result under “The 
masquerade.”) 

When fewer than one third of the 
processors in a complete network are 


traitorous, deterministic agreement 
without authentication is possible. The 
solution given in Lamport, Shostak, and 
Pease requires a number of messages 
that is exponential in the number of 
individuals. Other researchers later 
showed that a polynomial number of 
messages will suffice for solving the prob¬ 
lem under the same constraints. 

Fischer, Lynch, and Merritt 4 extend 
the Lamport, Shostak, and Pease result 
to show that additional problems arise 
when the communication network is not 
complete. They define a graph’s con¬ 
nectivity as the minimum number of 
nodes whose removal partitions the 
graph into two separate components. 
For example, Figure 9 shows a graph 
with connectivity two. The nodes repre¬ 
sent processors, and the lines indicate 
communication between processors. A 
minimum of two nodes and their com¬ 
munications lines must be removed to 
partition the graph into separate com¬ 
ponents. 

Fischer, Lynch, and Merritt showed 
that Byzantine agreement is possible if 
and only if the graph representing the 
communications network between the 
processors has connectivity greater than 
2k + 1, where k is the number of Byzan¬ 
tine failures that can occur. In other 
words, if removing half the individuals 
can partition the remaining individuals 
into two or more noncommunicating 
groups, Byzantine agreement will not 
be possible. 

The masquerade. When Joan decid¬ 
ed to join Bob and Alice for 
lunch, without the ability to 
conduct a conference call, no¬ 
body could be sure who was 
honest. We first show that 
with three agents and at most 
one possibly faulty agent, the 
other two agents cannot 
agree on whether or not to 
meet. Intuitively, the diffi¬ 
culty is that Bob, assuming 
he is honest, cannot distin¬ 
guish between the case where 
Alice is lying and the case 
where Joan is lying. 

Fischer, Lynch, and Mer¬ 
ritt give a simple proof of 
this idea. Suppose there was 
an algorithm that solved the 
problem at hand. Figure 10 
illustrates three scenarios 
leading to the failure of any 
Byzantine agreement proto- 



Figure 10. Scenarios leading to failure of Byzantine agree¬ 
ment. 
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Table 2. Conditions required for consensus. 
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col that does not use authentication. 
There are three agents, A, B, and C. In 
scenario 1, A is faulty. B and C start with 
the same input value, 0. B sees A start¬ 
ing with a value of 0, and C sees A 
starting with a value of 1. By the validity 
condition, the algorithm should ensure 
that B and C both decide 0. 

In the second scenario, B is faulty, A 
starts with a 1, and C starts with a 0. If B 
sends the same messages to C as it did in 
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the first scenario, C will see the same 
situation as in the first scenario. (We 
assume that in the first scenario A, the 
traitor, sent the same messages to C as 
in this scenario.) Therefore, the algo¬ 
rithm must once again decide 0. 

The third scenario is one in which A 
starts with a 1, B starts with a 1, and C is 
faulty. If C sends the same messages to 
A as it did in the second scenario, then 
A sees the same situation as in the sec¬ 
ond scenario. (We assume that in the 
second scenario B, the traitor, sent the 
same messages to A as in this scenario.) 
Again, the algorithm must decide 0. 
However, the two nonfaulty processors 
both have an input value of 1, so the 
decision of 0 violates validity. This proves 
that consensus is impossible. 

This result can be extended to an 
arbitrary number of processors by di¬ 
viding the processors into three equally 
sized groups of processors. Allowing 
one of the groups to contain all the 
faulty processors, the three scenarios 
can again be simulated. The simulation 
proves the general result that Byzan¬ 
tine agreement is not possible if one 
third of the processors are faulty. 

Sign on the dotted line. As we saw, if 
one of either Joan, Bob, or Alice is 
malicious, then the malicious one can 
send conflicting messages to the other 
two. Suppose Joan is the malicious one. 
Even if Alice forwarded Joan’s message 
to Bob, Bob would not know if Alice 
was forging Joan’s message or if Joan 
was being insincere. Therefore, he does 
not know whom to agree with. 

However, if Alice forwards a photo¬ 
copy of Joan’s message, Bob can see 


that the writing is truly Joan’s and will 
become immediately aware of the fact 
that Joan is, the malicious individual. So 
he agrees with Alice. Joan is foiled. 

This approach avoids problems be¬ 
cause the traitorous agent can no longer 
send any message he or she wishes, since 
signatures cannot be forged. In comput¬ 
er systems, algorithms that guarantee 
that signatures are not corrupted are 
called authentication algorithms. Encryp¬ 
tion provides the basis for authentica¬ 
tion. Lamport, Shostak, and Pease give 
a simple authentication algorithm. 

For the sake of simplicity, we assume 
the existence of a unique coordinator, 
C. When the coordinator is honest, all 
honest agents will output the coordina¬ 
tor’s initial input. When the coordina¬ 
tor is dishonest, all honest agents will 
output a 0. The algorithm proceeds in t 
+ 1 phases. Each message sent by a 
processor carries the signatures of all 
processors that have seen and transmit¬ 
ted the message. In phase i, there should 
be i signatures (in addition to the coor¬ 
dinator’s) and no duplicates. That makes 
the message legitimate. 

• Phase 1. The coordinator signs and 
sends an initial value to all agents. This 
constitutes their input. Note that the 
coordinator may send different initial 
values to different processors or may 
fail before sending messages to all pro¬ 
cessors. 

• Phase 2 through t + 1. First, each 
agent signs and sends all legitimate 
messages received in the previous phase 
to all the processors. If the message is 
legitimate, then the agent records the 
value contained in the message. 

•At the end of phase t + 1. An agent 
decides v if v is the only legitimate value 
it received. Otherwise, it decides 0. 

The algorithm satisfies termination: 
It ends after t + 1 phases. The algorithm 
satisfies validity: If all processors func¬ 
tion correctly and all have the same 
input, then they will agree on their ini¬ 
tial input. The algorithm satisfies con¬ 
sistency: All correctly functioning pro¬ 
cessors will see the same values as all 
other correctly functioning processors 
and therefore will reach the same deci¬ 
sion. With less than t + 1 phases, it is 
possible for an adversary to force dif¬ 
ferent processors to reach different de¬ 
cisions. 

Dolev and Strong 12 improved this ex¬ 
ponential algorithm by noticing that old 
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messages do not have to be present. 
Their algorithm sends a number of mes¬ 
sages that is quadratic in the number of 
processors. 


I n summary, for a group of proces¬ 
sors to arrive at a common deci¬ 
sion, they must solve the consen¬ 
sus problem. Distributed-system design¬ 
ers can save time by knowing the situa¬ 
tions in which no algorithm is possible 
for consensus and those in which algo¬ 
rithms have already been discovered. 

The fine line between impossibility 
and possibility trades processor reliabil¬ 
ity against network reliability. The more 
reliable the processors, the less reliable 
the network must be. 

• In a synchronous distributed system 
with reliable message delivery and pro¬ 
cessors subject to Byzantine failures, 
consensus is possible as long as fewer 
than one third of the processors fail. 

• In an asynchronous distributed sys¬ 
tem with reliable message delivery and 
processors subject to failure by stop¬ 
ping, consensus is not possible even if 
only one processor can fail. (Table 2 
summarizes the conditions under which 
consensus is possible in different asyn¬ 
chronous systems.) 

• In a synchronous distributed system 
in which messages can be dropped, con¬ 
sensus is not possible even if none of the 
processors fail. 

Shared memory increases the reli¬ 
ability of the communications medium. 
It is essentially equivalent to adding a 
broadcast capability to a network. This 
avoids many of the problems created by 
Byzantine failures, but not the prob¬ 
lems created by asynchrony. To solve 
these problems requires adding syn¬ 
chronization primitives such as 
compare&swap. The power of shared 
memory depends on the primitives it 
supports. 

Finally, techniques such as random¬ 
ization and authentication offer ways to 
overcome many impossibility results and 
often yield efficient algorithms. 

Besides being useful, the consensus 
problem has resulted in many elegant 
impossibility proofs. These proofs teach 
a simple moral that we should all take to 
heart: Global knowledge is much stron¬ 
ger than local knowledge. 

Or to put it in terms of our parable, 


Bob and Alice should ask to share an 
office. ■ 
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Information Encoding 
with Two-Dimensional 
Bar Codes 


Theo Pavlidis,* Jerome Swartz, and Ynjiun P. Wang 
Symbol Technologies 


Two-dimensional bar 
codes and matrix 
solutions provide 
greater information 
density than 
conventional bar 
codes for applications 
that require encoding 
of explicit information 
rather than 
database key. 


he last five years have seen the introduction of a new form of bar code with 
much higher density than the bar codes used in supermarkets and other 
stores. The new codes meet a need to encode significantly more data than 
. is now possible with conventional bar codes. 'Convent inpa) bar codes usually 
”s Jo dat abases (the term “ licens g plate” is used in the indust ry to 
rnpte, thelrarcode 


_ ir code of a supermarket item consists 

J 5f 11 digits thaFTbpresent an identifying number but not a product description. 
However, the data fields might be significantly coded — for instance, the price 
lookup is accessed in a database keyed to the number in the bar code. 

While a price lookup file is necessary and conveniently available in a retail 
environment, this may not be the case at a distribution center that receives from 
and ships to remote warehouses or overseas depots. Such applications require a 
much longer bar code (or other encoding) to store all the relevant information, 
such as price, product name, manufacturer, weight, inventory data, and expiration 
date. The code would be a “portable data file” because the information could be 
retrieved without access to a database. 

Bar codes have an apparent weakness in terms of information density: The 
vertical dimension does not carry any information. It only provides a redundancy 
that enables decoding of partially damaged symbols (because of stains, scratches, 
and so on) and also allows for imperfect scans when the user is not careful about 
orientation and registration bounds. The latter feature is very important in 
supermarket applications because of the type of scanners used there, but in other 
applications it is not a requirement. Also, in some applications the bar code may 
not be subject to the rough handling of supermarket packages, or it may be cost- 
effective to print extremely durable labels. Therefore, we should be able to 
increase the information density by using the vertical dimension at the cost of more 
careful scanning or more expensive equipment. 

Hospitals provide an example of an application in which high density is required 


•Pavlidis is with the Department of Computer Science, State University of New York at Stony Brook, and 
serves as scientific adviser to Symbol Technologies. Parts of this article were included in a paper presented 
at the IEEE Industrial Automation Conference, Toronto, June 1990. 
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and careful scanning and handling of 
the label is possible. Bar codes on p a¬ 
tient s’ bracelets c ould record informa¬ 
tion about medication. A nurse would 
's can th ebraceletainHhen administer 
the indicated m&dication in accordance 
with the patient’s prescribed regimen. 
This would be more reliable than read¬ 
ing a chart posted near the bed. 

The s hipping indu stry provides an- 
other example. When a package is sent 
from one place to another, the sender 
must also send a description of its con¬ 
tents. This shipping list is often attached 
to the package, but this method does 
not allow a quick update of the recipi¬ 
ent’s computer files. Electronic data 
interchange (EDI) has been proposed 
as a solution. The shipping list is sent 
electronically from the sender to the 
recipient with the bar code on the pack¬ 
age providing the key to the shipping 
list. However, ^pif aces serious p ra&i- 
cal limitation s whenthe sender and the 
recip ient are in different co uatriesLnr in 
a country with a very unreliable co m¬ 
munications network —-~or when net- 
worki~ar<rdisrupted during emergency 
conditions. A portable data file con- \ 
taining theshipiunfrlisEeyffeffr-ar Lalter- 
n ative to EDI. Because such labels will 
be subject to rough handling, codes t hat , 
allow^ error correcti on_ar e des irable. J 

This article reviews the various 
schemes proposed to meet the challenge 
of storing more information in the bar 
code label, or symbol, in the language of 
the industry. It extends the results of a 
previous article 1 that discussed in gen¬ 
eral terms the use of bar codes for infor¬ 
mation encoding. In the next section, 
we introduce the concept of informa¬ 
tion density. Then we deal with the con¬ 
straints imposed by the reading tech¬ 
nology and survey various recently 
proposed stacked bar codes. We also 
discuss certain non-bar-code solutions. 

Information density 

To label items with the contents of a 
database record instead of a key to such 
a record, we must increase the informa¬ 
tion density on such labels. Two ap¬ 
proaches have been proposed. One is to 
reduce the height of bar codes. Theo¬ 
retically, the optimal arrangement is a 
very thin and very long bar code, but 
such bar codes are not practical. Usual¬ 
ly there is a fixed area where the infor¬ 
mation must be printed, and the practi¬ 


cal solution is to stack labels to create a 
stacked or two-dimensional bar code. 
The plain act of stacking bar codes de¬ 
creases rather than increases informa¬ 
tion density because of the potential 
interference between rows. The increase 
in density occurs because of the reduc¬ 
tion in height. 

The other approach for increasing 
information density is to encode it in a 
way entirely different from the method 
used in bar codes. In particular, we ad¬ 
dress the following abstract problem: 
Given a rectangular area, devise a scheme 
of subdivision into regions having one 
of two colors so that the recorded infor¬ 
mation is maximized. If we have no oth¬ 
er constraints, the problem has a simple 
theoretical solution. Pack the area with 
as small regions as the printing technol¬ 
ogy allows and obtain a two-dimension¬ 
al binary pattern. If the resulting check¬ 
erboard has dimensions H x W 
(measured in terms of the narrowest 
element that can be printed), then we 
can create 2" w patterns. In this case, the 
information density will be 

H = 1 bit/pixel (1) 

which is the theoretical maximum. 

However, in practice we have many 
constraints, including those imposed by 
noise and distortions and by limits on 
printing and reading costs. As we showed 
in our previous article, 1 the bar code 
structure evolved in response to the 
need to read labels of unknown size at 
different distances (self-clocking) and 
to the need for immunity against certain 
kinds of distortion and noise. A check¬ 
erboard code without the safeguards of 
bar codes requires quite different read¬ 
ing technology (see the next section). 

For our discussion of stacked bar codes 
and checkerboard codes, we introduce 
the following notation: 

• X is the module width of the code, 
equal to the narrowest printed element 
that can also be resolved by the reader 
(equivalent to pixel width in the digital 
image processing terminology). 

•h is the height of a data row (bar 
code or checkerboard) expressed as a 
multiple of the module width X. This is 
equal to the aspect ratio of the narrow¬ 
est element. 

•m is the number of modules per 
code word. 


• w is the number of code words per 
row. 

• (|) is the maximum allowable tilt an¬ 
gle of the scan line with respect to the 
orientation of the rows. 

If we insist that a scan line must lie 
entirely within a data row, then the quan¬ 
tities h,m,w, and <|) are connected by the 
equation 

tan(()>) = ~— (2) 

We can relax the constraint on <|> by 
allowing “stitching” of partial scans: If a 
data row is not read by a single scan line, 
its different parts can be read by sepa¬ 
rate scan lines and assembled later. 2 
Then we need to keep a scan line only 
within a single code word, so maximum 
tilt angle is given by 

tan ( < t ) ) = ~ (3) 

These equations do not take into ac¬ 
count the finite spot size of the scanning 
device. When 1 < h < 2, we must replace 
h by h - c, where c is a constant with 
typical values between 0.6 and 1. In 
practical applications, h is always great¬ 
er than 2, and we can ignore the adjust¬ 
ment. For this reason, we use only the 
simpler expressions here. 

The information content of two-di¬ 
mensional code (stacked bar code or 
checkerboard) is defined in the usual 
way: 

S = log 2 /V bits (4) 

where N is the number of possible code 
words in the code. The definition of 
density requires more care because it 
must allow comparing different codes 
under similar scanning conditions. For 
given h and m, we can compute the code 
word density 

W(h,m) = bits/pixel (5) 

hm 

To compute the symbol density, we 
must either fix the height on each row or 
express the density in terms of the al¬ 
lowable tilt angle <|>. We must also dis¬ 
tinguish between density for stitchable 
symbologies and density for nonstitch- 
able symbologies. In the former case a 
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Figure 1. Relative position of scan lines (heavy lines) and data rows (diagonally shaded): (a) The ideal situation has one 
or more scan lines inside each data row; (b) the scan lines are still parallel but are tilted with respect to the data rows so 
that each scan line intersects more than one row of data; (c) the worst possible case — nonparallel scan lines — is com¬ 
mon with hand-held scanners. 


scan line need be kept only within a 
code word, while in the latter it must be 
kept within a data row. In the former 
case, h is given by Equation 3, and the 
area of a code word is m 2 tan (<|>). For 
nonstitchable symbologies, h is given by 
Equation 2, and the area of a code word, 
hm, is given by wm 1 tan (<|>). Therefore, 
the density is given by 

H(w,m,<\>) = —- bits/pixel 

m tanc|) 

(6a) 

for stitchable symbology, and by 

S 

H(w,m,^) = --- bits /pixel 

wm tanty 

(6b) 

for nonstitchable symbology. In this 
article, we omit some arguments of these 
expressions if they are fixed for a given 
code. Also, we denote the density, in¬ 
cluding symbol overhead (start and stop 
characters, checksums, and so on), by 
H°( . . . R), where R is the number of 
rows per symbol. 


Scanning methods 

Regardless of the method used for 
encoding information on paper, there 
are two basic approaches for reading it. 
One is to store a two-dimensional im¬ 
age of the reflectivity from the code 
obtained, for example, by a charge-cou¬ 
pled device camera. In this case, the 
representation will be a function of two 
variables /(/, /), where i and j are col¬ 
umn and row indices. The other ap¬ 
proach is to store a sequence of linear 


scans obtained, for example, by a laser 
scanner. The representation will be a 
set of functions of one variable 
F (f), where 1 < i < N if N is the number 
of linear scans and t is the time. (Time 
intervals correspond to the lengths of 


the printed bars and spaces.) When 
stacked bar codes are scanned by hand¬ 
held scanners, the scan lines need not be 
parallel, nor in any particular order. 
(Hand-held scanners display a single 
scan line, which is moved over the label 





mi ii iiiiii i ii i 


(a) 



Figure 2. Each 
block of the tall 
code (a) contains 
one or more lines 
that are entirely 
within it. This is 
not true for the 
short code (b). 


Figure 3. Markers 
used to identify 
position, scale, and 
orientation. 
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by hand motion in a rather unpredict¬ 
able way.) 

The major problem in reading two- 
dimensional symbols is the loss of verti¬ 
cal synchrony. Scan lines or lines with j 
constant need not coincide with the 
horizontal lines of the pattern, as Figure 
1 shows. In addition, there is the self¬ 
clocking problem for one-dimensional 
codes. 1 

Because scan lines may cross data 
rows, we must solve the following prob¬ 
lem: Given F t ( t ) (1 < i < N), identify the 
data row (or rows) from which each 
value has been taken. Since no absolute 
measure of size is available, we cannot 
perform an angle estimation. We need 
an inherent labeling scheme for each 
row that for a given small set of Fj(t) 
identifies any row transition. Then each 
set of scans could be partitioned into 
data row clusters: 

i^OoC {*,»)£' 

- (7) 

We can reconstruct data rows using a 
string matching algorithm. 2 

One way to avoid the vertical syn¬ 
chronization problem is to ensure that 
each scan line lies entirely within a data 
row. This simplifies processing but de¬ 
creases information content, because 
data rows must be tall enough for a 
single scan to stay within a single row 
(see Figure 2). 

Because the order of scan lines read is 
not the same as the order of data rows, 
a row identifier is needed even when 
scan lines are contained entirely in data 
rows. The lack of order is due to two 
factors: equipment limitations (for ex¬ 
ample, hand-held scanners) and the need 
to rescan some rows if they were not 
decoded the first time. 

In summary, if a code is to be read by 
linear scans, it must have the following 
features: 

• self-clocking for horizontal synchro¬ 
nization, 

• row number identifier, and 

• vertical synchronization provided by 
a local row discriminator or by an 
aspect ratio large enough to ensure 
that each row contains at least one 
scan line. 

The aspect ratio is defined as the ratio 
of row height over module width, de¬ 
noted by h above. 


The alternative method of scanning is 
to capture the symbol image in an array 
f Then we can use static techniques 
to identify the area of interest. Figure 3 
shows a label with markers used to find 
position, scale, and orientation. This 
method can be used for both stacked bar 
codes and checkerboard encodings. It 
requires capturing the whole image and 
thus demands more memory than tech¬ 
niques that capture only individual scan 
lines. Also, further processing by image 
analysis techniques requires more com¬ 
putation than the analysis of linear scans 
because of the larger data volume. Es¬ 
sentially, there is a trade-off between 
the cost of aiming the scanner at the 
label and processing only linear scans 
and the cost of processing an image with¬ 
out worrying about aiming. 

It is possible, at least theoretically, to 
rescan the image after determining the 
label’s position, scale, and orientation 
(angle <|> in Figure 3). Indeed, it is possi¬ 
ble to collect values off (i, j) along lines 
with the equation 

x cos (|> + y sin (j) + d = 0 (8) 

where d varies to cover the area of the 
code. The major practical difficulty is 
that while f(i,j) is defined only on inte¬ 
ger i and points satisfying Equation 8 
will not be integers in general, and we 
must use approximations. 


Stacked bar codes with 
large aspect ratios 

Three stacked bar codes with large 
aspect ratios have been proposed: Code 
49, 3 which stacks (16, 4) codes; Code 
16K, 4 which stacks Code 128; and Ident- 
code MLC-2D, 5 which stacks Code 39.' 
All these codes use thick black lines 
(equal to one module in vertical thick¬ 
ness) as row separators. If a scan line 
intersects a separating line, then the 
resulting sequence of intervals includes 
a very wide bar, provided the angle of 
intersection is small. Such a wide bar is 
detected during decoding, and the scan¬ 
ning results are rejected. However, if 
the scanning is done at a large angle, the 
width of the separating line appears 
comparable with the width of the regu¬ 
lar bars (see Figure 4) and separation is 
no longer reliable. 

Code 49. Designed by D. Allais and 
proposed by Intermec Corp. in 1987, 
Code 49 was one of the first codes to 
take advantage of the high capacity of 
(n, k) codes with large n, 1 and the first 
stacked code to do so. Figure 5 shows 
examples of Code 49 symbols. 

The code is based on a (16,4,6) delta 
code that has 6,147 possible code words. 1 
Code 49 encodes 49 characters: the al- 
phanumerics (A through Z and 0 through 



line produces an interval of width comparable to that of bar elements. 
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Table 1. Row numbering system for 
Code 49. 


Row 

Parity Pattern 

1 

OEEO 

2 

EOEO 

3 

OOEE 

4 

EEOO 

5 

OEOE 

6 

EOOE 

7 

OOOO 

Last 

EEEE 


9), some punctuation marks, and some 
special characters. It offers five modes. 
In one mode, a pair of characters is 
mapped onto a code word; in another, 
10 digits are mapped onto three code 
words. For the first case, 49 x 49 or 2,401 
code words are needed. 

Code 49 has two sets of code words 
with odd and even parity, so it uses a 
total of 4,802 code words. Each row 
contains a start and stop character and 
four code words of even and odd parity. 
The start and stop markers have two 
and four modules respectively, so a row 
has a total of 70 modules (2 + 4x16 + 4). 
The height of the row is specified at 
eight modules, plus one module for the 
separating line. 

The arrangement of code words of 
different parity indicates row number, 
as shown in Table 1. There, E stands for 
a code word of even parity and O for a 
code word of odd parity. Therefore, a 
symbol can contain at most eight rows. 
The convention is that even when the 
number of rows is less than eight, the 
last row has the EEEE parity pattern. 
Depending on the mode, there will be 
eight characters or 12 digits per row. 
When eight characters are encoded, sev¬ 
en are data and the last one is for parity 
check. To ensure containment of scan 
lines, the height of each row is specified 
at eight modules. The first three code 
words of the last row are weighted check¬ 
sums, and the fourth code word stores 
the total number of rows and informa¬ 
tion about the starting mode. There¬ 
fore, Code 49 is a very secure code: It is 
highly unlikely that a symbol will be 
read incorrectly. (For details on Code 
49, see Palmer. 3 ) 

The information content of the code 


S 49 = log 2 2,401 = 11.23 bits (9) 


The density per code word of a symbol 
that is m = 16 modules wide and h = 8 
modules tall is 


W 49 =-r- = -£m = 0.117 bits/pixel 
hm 8x16 

( 10 ) 

The density in terms of the tilt angle 
> defined by Equation 6 b is 


#49 ( 4 >) = 


S 49 11.23 


Hw 2 tan<]> 4xl6 2 xtan<|> 

0.0109 _ 1 

- bits / pixel tan <b > — 

tan<|> 32 

( 11 ) 


The maximum value of H A9 as a function 
of the angle is therefore 0.698, which is 
the same as the density of the one-di¬ 
mensional (16,4,6) delta code. Howev¬ 
er, because of the finite size of the scan¬ 
ning beam’s spot, the maximum angle is 
less than that given in Equation 11 and 
therefore the density is bound to be 
lower. For the current parameters of 
Code 49, tan $ equals 1/8 (h equals 8 , w 
is 4, and m is 16), so the maximum 
allowable tilt angle <|> is about 7 degrees. 
In this case, the density is 


# 49 ( 7 °) = —j-y^— = 0.0872 bits/pixel 

( 12 ) 

Reducing the tilt angle allows a re¬ 
duction in the row height with a respec¬ 
tive increase in density. We should also 
adjust the above measure for the over¬ 
head caused by the dividing lines, the 
start and stop code words, and the check¬ 
sums. The first factor causes a reduction 
of eight ninths. The start and stop code 
words each equal about one fourth of a 
regular code word, and the checksum 
half a code word. Thus, a row of four 
code words occupies space for 4.5 code 
words and uses only 3.5 code words for 
data. Because the last row consists only 
of checksums, there is another reducing 
factor. If R is the number of data rows, 
then the density //^taking into account 
the overhead is 


(13a) 

and 

rt 4 ° 9 ( 4 >, 7 ) = 0.605f/ 49 = 0-00659 bits/pixel 
tan<(> 

(13b) 


The density for module height equal to 
eight times the module width is 

# 49 (7 a i7) = 0.0527 bits/pixel 

(14) 

Code 16K. Code 16K was designed 
by T. Williams and proposed by 
Laserlight Systems in 1988. Each row 
has a start and stop character from the 
Universal Product Code (seven mod¬ 
ules each), plus five code words from 
Code 128 (11 modules each). Thus, the 
total is 70 modules: (7 + 5x11+7) plus 
one module for synchronization. The 
row number is encoded in the UPC 
characters, and the number of rows 
must be between two and 16. (For 
details on the symbology, see Longa- 
cre. 4 ) 

Because Code 128 has 106 distinct 
code words, the density is given by 


# 16K w=—- ? - i° 6 =- 6 ' 728 

wm 2 tan <|> 5 x 121 x tan <|> 

= M104 d 

tan<|> 

(15) 

Dividing Equation 15 by Equation 11 
yields 

^ = 0.95 (16) 

Therefore, Code 16K has slightly lower 
density than Code 49. Assuming a tilt 
angle with tangent 1/8 (<|> = 7 degrees) 
yields 


#i6K(7°) = -^r^ = 0-0832 bits/pixel 
(17) 

The overhead consists of one code 
word per symbol indicating the num¬ 
ber of rows, two code words per sym¬ 
bol serving as checksums, and two 
UPC code words per row. Therefore, 
each row uses five code words for 
data or 55 modules out of a total of 70 
modules. The last row has only two data 
code words, that is, 22 modules 
out of 70. Code 16K does not specify 
the module height. For overhead est¬ 
imation we assume that it is eight, so 
the loss of area because of the sep¬ 
aration bars will be eight ninths. If 
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R is the number of rows, then 


The minimum practical value of w is 5. 
Therefore, 


Code with small aspect 
ratio rows: PDF417 


9| 70 R 70 R 
0.419 


= - 0.700- 

9L 

2 <i?< 16 


( 22 ) 


| "i«(0) 
(18) 


"mi 


_ 2.74 „ 


< 0.548 bits / pixel 
(23) 

Assuming tan <|> equal to 1/8 yields 


" 6K (0,16) = 0.682 tf 16K (0) = - 


(19) 


and 


TT 0.0299 0.2392 

"mLC- 2D v ' ) - w I g ~ w 

<0.04784 bits /pixel 

(24) 


The need to confine scan lines within 
a data row reduces information density. 
The thick lines used to separate rows in 
the codes described in the previous sec¬ 
tion do not differ much from bars if the 
scanning is done at a significant tilt, as 
shown in Figure 4. Such codes need a 
row discriminator in addition to the row 
indicator. Using the methodology pre¬ 
sented in our earlier article, 1 we de¬ 
signed Code PDF417, which was pro¬ 
posed by Symbol Technologies in 1989. 
This code departs from earlier bar codes 
(including stacked bar codes) in the fol¬ 
lowing significant ways: 


//" 6K (7°,16) = °.°5 67 bits/pixel 

( 20 ) 


Because of the lower overhead, Code 
16K has a slightly higher practical den¬ 
sity than Code 49 (0.0567 versus 0.0527), 
but at the expense of security. 


Identcode MLC-2D. In 1989 a Ger¬ 
man company, ICS Identcode Systems, 
proposed Identcode MLC-2D in two 
versions: Identcode MLC-2D Alpha uses 
rows of Code 39, and Identcode MLC- 
2D 25 uses rows of Code Interleaved 2 
of 5. Here we discuss only the former 
because it has higher density. It has 
identical start and stop code words for 
each row (the * character of Code 39), 
so the code may be framed by what 
appear to be vertical and horizontal 
bars. The first character of each row 
after the start code word and the last 
before the stop code word are row indi¬ 
cators. There can be from one to 22 
rows and from two to 61 code words per 
row. (More details are available else¬ 
where. 5 ) 

We compute the density of this code 
as follows. We assume a wide-to-nar- 
row ratio of 2.5 for Code 39, which 
yields log 2 5/m equal to 0.404 and m 
equal to 13.5. (See Table 3 in our previ¬ 
ous article. 1 ) Then 


"mLC-2D (0) 


0.404 

wl3.5tan0 

0.0299 . 

:- bits / pixel 

wtan0 

( 21 ) 


The overhead consists of four code 
words per row and one code word per 
symbol. If R is the number of rows, then 

h Zujmd( w >+’ R ) 

(w-4)(7?-l) + (w-5)„ 

~- - - n MLC-2D191 

Rw 

= |"l p 1 "mLC-2D (0) 

L w 

(25) 

where 1 < R < 22. Substituting H MLC . 2D (i|>) 
from Equation 21 results in an expres¬ 
sion for the density that is the product of 
two terms, one increasing and the other 
decreasing with w. A simple differentia¬ 
tion shows that maximum density occurs 
for 

w mxx =2 4 -l"! =8 if 7?>4 (26) 


For that choice of code words per row, 
Equation 23 suggests that Identcode 
MLC-2D without overhead has only 34 
percent of the density of Code 49. If the 
overhead is included, then 


H° 


,(8,0,22) = 


L_4_ _1 0.0299 

[ 8 8-22 J8tan0 


0.00185 

tan0 


bits / pixel 


(27) 

which is about one quarter the density 
of either Code 49 or Code 16K. Finally, 
for tan 0 equal to 1/8, 

"mlc- 2 d( 8 ’ 7 ° 22 ) = °- 0148 bits/pixel 

(28) 


•It allows stitching of partial scans 
and therefore laser scanning angles much 
greater than those of other codes for a 
given density. This makes possible non- 
contact laser hand scanning in addition 
to charge-coupled device scanning. 

• It allows not only error detection 
(self-checking) but also error correc¬ 
tion. 

• It considers channel and source en¬ 
coding separately. Bar-space combina¬ 
tions yield 929 code words, and each can 
be assigned a meaning by selecting one 
out of 15 assignment tables (modes). 

•It offers a security versus density 
trade-off. 

Code PDF417 has three predefined 
modes: ASCII, binary, and numeric. It 
also has nine user-defined modes. In 
the ASCII mode, we can encode the 
alphanumeric data in double density 
(two characters per code word). In the 
numeric mode, the numeric data can be 
packed in almost triple density. 

Every Code PDF417 symbol is com¬ 
posed of a series of rows, each using a 
(17,4,6) code with 17 modules arranged 
into four bars and four spaces. No bar or 
space has a width greater than 6. The set 
of code words is partitioned into three 
mutually exclusive subsets called clus¬ 
ters. Each row uses only one of the 
three clusters to encode data. Each clus¬ 
ter repeats sequentially every third row. 
Because any two adjacent rows use dif¬ 
ferent clusters, the decoder can stitch 
partial scans while decoding a very high 
density Code PDF417 symbol. 

Every Code PDF417 symbol has a 
user-defined error-correction capabili¬ 
ty of up to 512 code words. Details 
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about the code characteristics can be 
found in the Code PDF417 specifica¬ 
tion manual. 6 Figure 6 shows the struc¬ 
ture of a code word and Figure 7 the 
structure of the symbol. 

Code word clusters are defined ac¬ 
cording to the following discriminator 
function: 

f(x) = (x 0 -x 2 +x 4 -x 6 ) m o as (29) 

where x represents a code word element 
vector, as shown in Figure 6. Here x 0 , x 2 , 
x 4 , and x 6 represent the widths of various 
bars; x u x 3 , x 5 , and x n , those of various 
spaces. The sequence x 0 , x u . . . , x n is 
called the x-sequence. There are nine 
possible values off (x). Code words with 
the same value are assigned to the same 
Figure 6. Structure of the code word of Code PDF417. For the values given in cluster. The clusters with numbers 0, 3, 
the figure, the cluster number is (2 - 1 + 3 - l) raod9 = 3. and 6 are the only ones used, according 

to the rule of Equation 30: 


Module# 1 23456789 1011 1213141516 17 

I I I II I I II I I I I I I i I I 

II III 


Element 211 5 3 212 

width 1 III 


*4 X 6 

*3 X 5 X 7 


Icator Codeword 


Right Row Indicator Codeword 
Stop Pattern 
Quiet Zone 



Figure 7. Structure of the symbol of Code PDF417. Quiet zones are areas that 
must be free of any printing. The start and stop patterns function as in conven¬ 
tional bar codes: They identify the symbol’s extent. 


N c = [(AR) mod3 ] x 3 (30) 

where N c stands for cluster number and 
N r for row number. For example, the 
cluster number of row 7 is 3. 

Code PDF417 uses the same start and 
stop code words for all rows so the sym¬ 
bol is bounded on the left and right by 
solid structures, as shown in Figure 8. 
Each row also contains two row indica¬ 
tor code words at both ends. 

The number of possible code words 
for each cluster is 929; therefore, S PDF417 
equals log 2 (929) or 9.86 bits. Because 
Code PDF417 allows scan lines to cross 
rows, the code is stitchable and Equa¬ 
tion 6a is applicable, yielding the fol¬ 
lowing expression for the density: 


Fourscore and sev¬ 
en years ago our fa¬ 
thers brought forth on 
this continent a new 
nation, conceived in 
liberty and dedicated 
to the proposition that 
all men are created 
equal. Now we are 
engaged in a great civ¬ 
il war, testing whether that nation or any nation so conceived 
and so dedicated can long endure. We are met on a great 
battlefield of that war. We have come to dedicate a portion of 
that field as a final resting place for those who here gave their 
lives that that nation might live. It is altogether fitting and 


proper that we should do this. But in a larger sense, we cannot 
dedicate, we cannot consecrate, we cannot hallow this ground. 
The brave men, living and dead, who struggled here have 
consecrated it far above our poor power to add or detract. The 
world will little note nor long remember what we say here, but 
it can never forget what they did here. It is for us the living, 
rather to be dedicated here to the unfinished work which they 
who fought here have thus far so nobly advanced. It is rather 
for us to be here dedicated to the great task remaining before 
us — that from these honored dead we take increased devo¬ 
tion to that cause for which they gave the last full measure of 
devotion; that we here highly resolve that these dead shall not 
have died in vain; that this nation under God shall have a new 
birth of freedom; and that government of the people, by the 
people, for the people shall not perish from the earth. 



Figure 8. Code PDF417 encoding the Gettysburg Address. 
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(31) 


H PDF417 _ 


9.86 
m 2 tan<)> 


Since m equals 17, Equation 31 becomes 


0.0341 

tanc|> 


bits / pixel 


(32) 


Assuming tan((|>) equal to 8 yields 
// PD f 4 i 7 (7°) = 0.273 bits / pixel 

(33) 

Also, 


^PDF417 _ 0-0341 .. 

H 49 0.109 


(34) 


This is an upper bound assuming the 
maximum allowable angle. Code 
PDF417 has four code words per row 
which do not contain data. Therefore, 
the row efficiency is (w - 4)/w. At the 
minimum security level, there is no fur¬ 
ther overhead. Therefore, 


HpDF417 ( VV > < J ) ) “ ~— HpDF417 (<t0 

(35) 

For w equal to 8 the result is 




tan(<]>) 


(36) 


A comparison of Equation 36 with 
Equations 13 and 20 shows that Code 
PDF417 has more than twice the densi¬ 
ty that Code 49 and Code 16K can 
achieve under their most favorable cir¬ 
cumstances. When tan (j> equals 1/8, the 
result is 


H; DF417 (8,7 0 ) = 0.136 bits/pixel 

(37) 

A Code PDF417 symbol may contain 
a number of error-correction code words 
depending on the desired security level. 
All data code words (but not the row 
indicators) form the symbol data poly¬ 
nomial with coefficients from GF(929):* 

d(x) = d 0 + d i x + ... + d„_, x" (38) 


*GF stands for Galois field. Definitions of the 
coefficients appear in most coding theory text¬ 
books, for example, the book by Lin and Costello. 7 



Figure 9. Arrangement of data, row indicators, row checksums, and words for 
error correction in a Code PDF417 symbol. 


Figure 9 shows the corresponding 
position of each code word value d i in a 
Code PDF417 symbol; in the figure, c, 
represents an error-correction code 
word. The total number of error-cor¬ 
rection code words is k, which can be 
one of eight possible values: {4,8,16,32, 
64,128, 256, 512). 

The error-correction code words are 
the complement of coefficients of the 
remainder b(x) = 6 s0 + . . . + b sk _, x k ~' 
resulting from dividing the symbol data 
polynomial by the generator polynomi¬ 
al g sk (x). The generator polynomial for 
an error-correction capacity of k is 

g s *(x) = (x-3)(x-3 2 )...(x-3‘) 

(39) 

The Code PDF417 specification manu¬ 
al provides the algorithm for error cor¬ 
rection. 6 

Because of ink spread, Code PDF417 
is decoded on the basis of the edge-to- 
edge measurements t 0 , t u .. . , t s , where 

Ipfa + x, (40) 

These measurements are quantized as 
integers in the interval. 26 Let 7) be the 
quantized set. The code word cluster 
number is given by 

N c = (T 0 - Ti + r 4 - T 5 ) moi9 (41) 

If the result is not equal to 0, 3, or 6, the 
code word is in error. The values T 0 ,...,T S 
plus the cluster number form a seven¬ 


digit key used for finding the numerical 
value of the code word in a lookup table. 

Non-bar-code solutions 

The bar codes discussed in the previ¬ 
ous sections represent open systems as 
seen from two different viewpoints. 
From the information-theoretic view¬ 
point, they are open because the size of 
the printed symbol, its distance from 
the scanner, and the conditions of illu¬ 
mination are unknown to the decoder. 
From a commercial viewpoint, they are 
open because the information needed 
to construct the encoder and the decod¬ 
er is in the public domain. Users can 
purchase encoders or decoders from 
many sources. The symbology design¬ 
ers have made the information public to 
increase the overall market for their 
products; they believe that users will be 
more likely to adopt a symbology if they 
know the needed equipment is avail¬ 
able from many suppliers. 

Some systems are closed from both 
viewpoints. The distance between the 
scanner and symbol is fixed, the illumi¬ 
nation is controlled, and, in some cases, 
the size of the symbol is fixed. The in¬ 
formation for encoding or decoding is 
not public, so a user must purchase a 
complete system from the code de¬ 
signer. 

In this section, we review some closed 
systems — without a detailed analysis 
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because their specifications are propri¬ 
etary information. Because we did not 
have complete access to specifications, 
we may have introduced some inaccu¬ 
racies in the following descriptions. 
However, we felt it was better to pro¬ 
vide at least a rough description of these 
codes rather than ignore them. 

Softstrip. Softstrip is described in a 
patent granted to Cauzin Systems in 
1988. 8 It is basically a Manchester code 
— that is, a zero is represented by 10 
(bar-space) and a one by 01 (space¬ 
bar). The code includes timing marks 
both at the start of the encoding (for 
vertical synchronization) and along the 
sides (for horizontal synchronization). 
Each line can have only an integer num¬ 
ber of half bytes (nibbles). Only a pro¬ 
prietary contact scanner can read the 
code. 

The system was originally proposed 
for printing in magazines computer code 
that readers could scan and load into 
their personal computers. It found only 
limited acceptance in that application 
and has since been used to store infor¬ 
mation on cards used in mass mailings. 

Since Manchester codes use two pix¬ 
els per bit and Softstrip imposes some 
horizontal separation between rows of 
data, the number of bits that can be 
stored in a rectangular area 2 HW is at 
most 2 Hr2(w) , where H and W are the 
dimensions of the area in pixels. Thus, 
the density should be at most 

loe„ 2 h/2W 

H softstnp -— -=0.5 bits / pixel 

(42) 

This figure does not include over¬ 
head. Equation 12 shows that the densi¬ 
ty of Code 49 is 0.0872, so Softstrip 
appears to be four times as efficient as 
Code 49 if we ignore the overhead for 
both codes. However, Code 49 can be 
read by noncontact devices from a vari¬ 
ety of distances, while Softstrip can be 
read only by proprietary contact scan¬ 
ners. 

Vericode. Veritec Corp. (founded in 
1982) proposed Vericode 9 for a variety 
of applications, with emphasis on the 
creation of electronic fingerprints. An 
item marked with Vericode can be 
scanned to reveal a special identifier. 
Since the encoding process is not pub¬ 
lic, it would be difficult, if not impossi¬ 



Figure 10. Example of a Datacode la¬ 
bel (this example does not necessarily 
present a legal code). 


Table 2. Datacode density. 


Redundancy 

(percent) 

Number 
of Pixels 

^Datacode 

0 

121 

0.549 

20 

289 

0.229 

33 

361 

0.184 

44 

961 

0.069 


ble, for someone else to create the same 
label. In its advertisements, the compa¬ 
ny emphasizes that the code is “highly 
encrypted.” Vericode appears to be a 
checkerboard code. A company bro¬ 
chure 9 shows an example in which 28 
characters are stored in 289 (17 x 17) 
pixels. If we assume that each character 
is equivalent to 5.46 bits (the bits need¬ 
ed to encode 26 letters, 10 digits, and 
eight punctuation marks), the estimat¬ 
ed information density is 


This estimate includes overhead and 
the expense of whatever error-detec¬ 
tion scheme is used. 

The company markets a system that 
includes printers, readers, and decod¬ 
ers, as well as the coding scheme. There¬ 
fore, there are no public details about 
the code’s structure. 


Datacode. Proposed in 1989, Data¬ 
code is a proprietary code of IDMatrix, 
Inc. 1011 In some ways it is similar to 
Vericode: It is a checkerboard code 


marketed as part of a system. However, 
while Vericode emphasizes security (se¬ 
crecy) of identification, Datacode em¬ 
phasizes storage of information. A ma¬ 
jor difference between the two labels is 
that the Datacode symbol contains a 
frame. Half of the frame is solid, and the 
other half has alternating black and white 
pixels (see Figure 10). The frame allows 
some self-clocking because it can be 
used to estimate the label orientation 
and the pixel size. Part of the data can 
be encoded by a secret code; a key cell 
indicates the code used. Redundancy 
can be provided by recording the data 
more than once in the matrix. 

A company brochure 11 provides a se¬ 
ries of examples for storing 20 digits 
that are equivalent to 66.4 bits. Each 
example has a certain “redundancy” 
associated with it. A simple calculation 
yields the numbers shown in Table 2. 

The company recommends at least a 
20 percent redundancy because Data¬ 
code uses a very long block code and 
even a single undetected error might 
destroy the whole message. The redun¬ 
dancy allows the use of error detection 
and error correction. 

Philips dot code 

Philips of Eindhoven, The Nether¬ 
lands, has developed a two-dimension¬ 
al code known as the Philips dot code. It 
is often mentioned as a possible alter¬ 
native to the two-dimensional bar codes 
and other codes discussed so far. How¬ 
ever, Philips developed this code for 
labeling small parts and not for storing 
a large amount of data on a label. A 
label consists of an 8 x 8 square matrix, 
as shown in Figure 11. The four corner 
dots are always present. A dot in the 
second position of the first row and one 
in the first diagonal position indicate 
the start corner for decoding. Eight dot 
positions are used for a check character. 
There are only 31 bits left for encoding 
data, which is equivalent to 4.4 ASCII 
characters. 

The major applications of the dot code 
are small-area, data-limited applications 
such as silicon wafer labeling and drug 
dosage labeling. Because it is limited to 
only 31 bits, the dot code cannot store 
the large amounts of data that the other 
codes discussed in this article can. If we 
juxtapose many dot codes to store large 
amounts of information, then the code 
will have properties similar to the check- 
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erboard codes described in the previous 
section. It may achieve higher density 
than the stacked bar codes, but it could 
be read only by charge-coupled device 
cameras. In addition, it would suffer in 
comparison with Vericode and Data- 
code because it would have to carry the 
orientation overhead in each block. 


T able 3 summarizes and compares 
the various encoding schemes. 
Clearly, there are significant 
trade-offs depending on the applica¬ 
tion. Closed systems offer more than 
double the density of open systems 
(about 50 percent of the theoretical 
maximum versus under 25 percent), 
provided that a controlled scanning en¬ 
vironment can be established. There is 
another caveat in the interpretation of 
the tabulated values: Those for the open 
systems and for text refer only to chan¬ 
nel encoding. Those for the closed sys¬ 
tems include source encoding as well; 
therefore, the higher densities may be 
achieved because of data compaction 
during source encoding. 

The developments described in this 
article show that we can reach very high 
densities for encoding information on 
paper. A code with information density 
0.2 can store 2,000 bits per square inch 
using pixels of 10-mil sides, well within 
the limits of printing and reading tech¬ 
nology. Because of block encoding tech¬ 
niques, this density is equivalent to about 
250 characters per square inch. In con¬ 
trast, text typed at the usual pitch of 10 
characters per inch and at eight lines 
per inch has a density of only 80 charac¬ 
ters per square inch. The “small print” 
frequently used in footnotes (8-point 
type) can fit a line of text in one ninth of 
an inch with about 18 characters per 
linear inch, yielding a density of about 
160 characters per square inch. Assum¬ 
ing 5.46 bits per character (see the sec¬ 
tion on Vericode) and square pixels 
with 10-mil sides, we get the following 
densities: 

^ d= lS = a ° 437 bitS/piXel 

(44) 

and 

5 46-160 

H Pnnle , = = 0.0874 bits/pixel 

Printed ^QQQ 

( 45 ) 
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Figure 11. Example of Philips dot 
code. The code consists only of solid 
circles. The empty circles in the figure 
show the available positions for the 
code. (The example does not neces¬ 
sarily present a legal code.) 


proposed codes, Code PDF417 achieves 
the highest density because it allows 
scan lines to cross data rows. The code 
requires more powerful processing to 
stitch together the partial scans. How¬ 
ever, the necessary computational pow¬ 
er is well within the limits of the current 
technology. (During the October 1990 
Scantech exhibition in Atlanta, Symbol 
Technologies demonstrated a real-time 
system for decoding Code PDF417.) 
Code 49 and Code 16K have about equal 
density, but Code 49 is more secure 
than Code 16K because it uses a larger 
number of checksums. Their density is 
about one half that of Code PDF417. 
Code Identcode MLC-2D has the low¬ 
est density. Code PDF417 is the first bar 
code to introduce error correction to 
compensate for the redundancy lost with 
reduced symbol height. ■ 


Both are well below the density of at 
least some of the stacked bar codes. 

Stacked bar codes increase the densi¬ 
ty of information under the constraint 
that the symbol be printed in a limited 
rectangular area. Of the four recently 
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Table 3. Information density of various codes (with overhead unless noted 
otherwise). 


Code 

Density 

Equation 


Name 

(bits/pixel) 

or Table 

Comments 

Codes that can be read with a hand-held or stationary scanner (open 

systems): 




Code 49 

0.0527 

(14) 


Code16K 

0.0567 

(20) 


Identcode MLC-2D 

0.0148 

(28) 


Code PDF417 

0.1364 

(37) 


Codes that can be read only with a stationary scanner (closed systems): 

Softstrip 

0.500 

(42) 

Without 

overhead 

Vericode 

0.529 

(43) 


Datacode 

0.549 

(Table 2) 

No 

redundancy 

Datacode 

0.229 

(Table 2) 

20 percent 
redundancy 

Codes that can be read only by people or OCR machines: 


Typed text 

0.0437 

(44) 


Printed text (8 point) 

0.0874 

(45) 
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Using Tool Abstraction 
to Compose Systems 


David Garlan, Carnegie Mellon University 
Gail E. Kaiser, Columbia University 
David Notkin, University of Washington 



Two complementary 
paradigms support the 
evolution of large-scale 
software systems. Data 
abstraction eases 
design changes in the 
representation of data 
structures, while tool 
abstraction does the 
same with system 
functions. 


M i: anaging complexity and supporting evolution are two fundamental 
I problems with large-scale software systems. 1 Although modularization 
J has long been accepted as the basic approach to managing complexity, 
as David Parnas observed nearly 20 years ago, not all modularizations are equally 
good at handling evolution. 2 

Data abstraction is a popular, important style of modularization. In this style, an 
abstract data type is defined by an explicit interface that specifies operations on 
instances of the data type. This approach defers design decisions about represent¬ 
ing concrete data structures and implementing algorithms on those structures. 
These concrete decisions can be changed without modifying the module’s clients, 
which are written in terms of the stable interface. 

Enhancing a system’s function typically accounts for about 60 percent of 
maintenance costs in a large system’s life cycle, and hence roughly 40 percent of 
total software life-cycle costs. 3 If the interfaces to abstract data types are kept the 
same to protect clients from evolutionary changes, enhancements must often be 
constructed in terms of existing abstract data types. This restriction can lead to two 
problems. The desired function may not be computable from the existing inter¬ 
faces, or implementing the function in terms of these interfaces may be unaccept¬ 
ably inefficient. 

Thus, modifying the abstract interface itself may be the most effective — or the 
only — way to enhance functionality. Changing the abstract interface, however, 
implies that the concrete implementation must be understood and changed, which 
increases the complexity of the task. While one such change to an existing data 
abstraction may not be a serious problem, as the number of enhancements 
increases so does the complexity of the interactions between them. 

Therefore, designers need an approach to handling changes that permits the 
system to be enhanced incrementally and modifications to be developed indepen¬ 
dently, even when the changes cannot be achieved by using traditional data- 
abstraction techniques. Several existing kinds of systems approximate these objec¬ 
tives. For example, spreadsheets are often enhanced by adding new equations that 
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Figure 1. Collection of toolies that share a set 
of abstract data structures. 


use the values in data cells to inter¬ 
act indirectly with existing equations. 

In another example, production sys¬ 
tems — a popular implementation 
paradigm for expert systems — con¬ 
sist of a collection of independent 
pattern-action pairs (called rules) 
that fire when the patterns match 
values in a shared database (called 
working memory). In principle, a 
production system can be enhanced 
by adding new rules that match and 
manipulate the working memory. 

We call the diverse set of systems 
structured in this style the tool-abstrac¬ 
tion paradigm. That is, despite some 
differences, each system of this sort has 
a common structure that encourages 
and eases incremental enhancement of 
system function, just as data abstraction 
encourages and eases changing design 
decisions about data representation. 
Rather than detract from the central 
idea of tool abstraction by introducing a 
new tool-abstraction mechanism, we use 
existing approaches to describe and ar¬ 
gue the benefits of tool abstraction. The 
s idebars throughout this article describe 
several of these approaches. 

Systems that support tool abstraction 
are structured as a pool of abstract data 
structures shared by a collection of co¬ 
operating “toolies,” where each toolie 
provides a piece of the overall system 
function. When one toolie updates the 
shared data, other toolies must be noti¬ 
fied; otherwise, cooperating-but-inde- 
pendent toolies may not execute, and 
the overall system function may be com¬ 
promised. Figure 1 illustrates this archi¬ 
tecture. 


At this level, tool abstraction resem¬ 
bles trigger-based database-manage¬ 
ment systems that provide access to 
shared data through a common set of 
schemas. As discussed later, each sys¬ 
tem handles notification differently, al¬ 
though most use an event-based ap¬ 
proach. 

Tool abstraction complements, rather 
than supplants, data abstraction. Data 
abstraction allows design decisions about 
the representation of data structures to 
change easily, while tool abstraction al¬ 
lows system functions to change easily. 

A simple example 

Consider a small message system cen¬ 
tered on a queue module that exports 
enqueue and dequeue operations only. 
Using abstract data types, how could we 
enhance the system so that it will not 
add duplicate messages? One approach 
is to modify the clients of the queue. 
However, this is unsatisfactory because 
to detect duplicates by using the origi¬ 
nal interface, the client would have to 


dequeue each message already on 
the queue, compare it to the new 
message to be enqueued, and then 
re-enqueue the original messages, 
plus perhaps the new one. Even 
though this activity could be encap¬ 
sulated in a new client, the perfor¬ 
mance penalty is severe. Specifical¬ 
ly, the number of enqueue/dequeue 
operations executed would be lin¬ 
ear in queue length. 

Another approach is to change 
the queue module implementation. 
The number of enqueue operations 
would drop to one, and no dequeue 
operations would be needed. However, 
this approach is unsatisfactory because 
the semantics (although not the syntax) 
of the enqueue operation must change. 
Thus, clients that want the original queue 
semantics (perhaps for some other use 
of queues) are not isolated from the 
change,Using data abstraction, this kind 
of problem must be handled by creating 
distinct abstract interfaces, each with 
different semantics. 

Both approaches are less attractive in 
the face of multiple enhancements. Con¬ 
sider a second enhancement that adds a 
time stamp to each message; this neces¬ 
sarily interacts with the prohibition 
against duplicate messages. In particu¬ 
lar, both enhancements must modify 
the implementation even though they 
may be conceptually independent. Fur¬ 
ther, the clients must usually be modi¬ 
fied to gain any advantage from the 
time-stamp enhancement. Again, this is 
further complicated when various cli¬ 
ents desire different semantics. Some 
clients might prefer to queue the dupli- 


Spreadsheets 

Spreadsheet programs have gained 
enormous popularity as flexible, exten¬ 
sible tools for financial accounting. 1 A 
spreadsheet can be viewed as a 
shared data pool represented by a ma¬ 
trix of values, with toolies represented 
by equations associated with positions 
in that matrix. When data in one of the 
matrix entries changes, the runtime 
system automatically reevaluates all 
equations that depend on that entry, 
updating the appropriate entries. Sup¬ 
pose an equation defines the rightmost 
value in a row as the sum of the row’s 
other values. If a user changes one of 
those values, the spreadsheet will au¬ 


tomatically reevaluate the sum. This in 
turn may trigger the reevaluation of other 
equations, such as one to add all values 
in the rightmost column. 

A spreadsheet’s toolie invocation mech¬ 
anism thus depends on dataflow analysis 
to determine which matrix entries affect 
which equations. Many spreadsheets 
have simple mechanisms that do not han¬ 
dle, or even identify, circular relationships 
among the toolies. Luckily, in the domains 
most generally addressed by spread¬ 
sheets, such circularities rarely arise. 

A spreadsheet system is not a general- 
purpose tool environment but a special¬ 
ized application generator. Consequently, 
the range of toolies that a spreadsheet 
implementer can describe is constrained. 


Nonetheless, spreadsheets exhibit the 
architectural hallmark of tool abstrac¬ 
tion: a shared pool of data together 
with event-driven control of function. 
Moreover, they effectively handle 
functional evolution: Circularities 
aside, equations can be added to the 
system independently of other equa¬ 
tions in the system. While complex de¬ 
pendencies may exist between these 
equations, the system rather than the 
programmer manages those interac¬ 
tions. 
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cate with the earliest time stamp, while 
others prefer to use the latest time stamp. 

Although this example is especially 
simple, it illustrates some tensions that 
arise when systems evolve. The use of 
tool abstraction shows how problems of 
evolution can be reduced. 

The message buffer serves as the 
shared data structure. One toolie pro¬ 
vides the basic enqueue and dequeue 
operations. To handle the first enhance¬ 
ment, a “remove duplicates” toolie is 
defined; after the initiation of each en¬ 
queue operation, this toolie is invoked 
to compare the message about to be 
inserted with all other messages, abort¬ 
ing the enqueue operation if the mes¬ 
sage is already in the queue. Because it 
has direct access to the message buffer, 
the toolie can be implemented with rea¬ 
sonable efficiency. (If needed, the too¬ 
lie can maintain an auxiliary represen¬ 
tation of the buffer, keyed by whatever 
component of a message is checked for 
duplication.) The “add time stamps” 
toolie, which defines the second en¬ 
hancement, is invoked when the en¬ 
queue operation terminates successful¬ 
ly. This toolie augments the newly 
inserted message with a field that repre¬ 
sents the current time. Maintaining cor¬ 
rectness is relatively easy, since each 
new toolie interacts only with the mes¬ 
sage-buffer representation and any oth¬ 
er toolie invoked by the same opera¬ 
tion, not with other toolies associated 
with the message queue. In this case, it’s 
unnecessary to specify the invocation 


order of these two toolies, since “re¬ 
move duplicates” is'invoked upon initia¬ 
tion of enqueue, while “add time stamps” 
is invoked upon its termination. 

The KWIC index 
production system 

As Parnas pointed out, the issue is 
not whether to modularize a system — 
since modularization is essential to the 
control of complexity — but rather how 
to design the best criteria for decom¬ 
posing a system design into modules. 
Parnas contrasted data abstraction with 
functional decomposition, showing that 
systems based on the former can better 
handle evolution for certain classes of 
change. We have taken this one step 
further. Tool abstraction reintroduces 
decomposition criteria according to func¬ 
tion but uses a composition paradigm 
based on sharing abstract data struc¬ 
tures (low-level abstract data types) 
among a collection of cooperating tools, 
together with an event-driven integra¬ 
tion mechanism. A bundle of toolies 
represents a higher level abstract data 
type, amenable to a wide range of en¬ 
hancements. This approach contrasts 
with the strict use of data abstraction 
and leads to better support for the more 
common classes of functional enhance¬ 
ments. 

Parnas used the KWIC (Key Word in 
Context) index production system to 
compare two modularizations with re¬ 


spect to ease of evolution. To further 
illustrate the idea of tool abstraction, 
we do the same. The first design we 
present is Parnas’s second decomposi¬ 
tion, which uses data abstraction to de¬ 
compose the system into modules. Our 
second design is based on the tool-ab¬ 
straction paradigm. We show how tool 
abstraction (along with data abstrac¬ 
tion) supports evolutionary enhance¬ 
ments more effectively than does data 
abstraction per se. Parnas describes the 
KWIC system as follows: 2 

The KWIC index system accepts an ordered 
set of lines, each line is an ordered set of 
words, and each word is an ordered set of 
characters. Any line may be “circularly 
shifted” by repeatedly removing the first 
word and appending it at the end of the 
line. The KWIC index system outputs a 
listing of all circular shifts of all lines in 
alphabetical order. 

As Parnas explains, this is a small 
system and consequently none of the 
motivating issues actually arise. Simi¬ 
larly, it’s hard to properly evaluate evo¬ 
lution issues in a system of this size. 
However, because it does let us point 
out the key issues and problems of tool 
abstraction, we follow Parnas’s lead in 
treating it as a large project that pre¬ 
sents realistic problems. 

Design 1: Parnas’s decomposition. 

Parnas decomposes the KWIC system 
into modules that hide specific data- 
representation and algorithm choices 
so that these choices can be changed. 


Production systems 

This popular implementation para¬ 
digm for expert systems typically con¬ 
sists of a collection of rules, where 
each rule is a pattern-action pair. The 
pattern defines the conditions under 
which the associated action should be 
applied (or triggered). Patterns are 
written in terms of the values of ob¬ 
jects in a shared database, called 
working memory. When several pat¬ 
terns apply to a particular database 
state, the system automatically con¬ 
trols the sequencing of corresponding 
actions, as determined by rule-order¬ 
ing policies that vary with the kind of 
production system. These systems are 
based on tool abstraction, with working 
memory representing the shared data 
pool and the production rules repre¬ 


senting the toolies. Interactions between 
the enhancement and existing functions 
are controlled by the production system 
itself. 

The Formalized System Development 
(FSD) system 12 and Marvel 3 are rule- 
based software-development environment 
architectures that are relatively close to 
pure tool abstraction. Each combines 
ideas from production systems and active 
data, and represents the software artifacts 
under development in an object-oriented 
database. Tool fragments are automati¬ 
cally invoked in response to chaining on 
the rules, which in turn can be triggered 
by changes to the data. In FSD, new rules 
and subclasses of existing objects can be 
added at any time to accommodate addi¬ 
tional Lisp tools. In Marvel, new rules, 
new classes of objects, and extensions to 
existing classes can be added at any time 


to integrate additional commercial off- 
the-shelf tools into the environment. 
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•The Line Storage module imple¬ 
ments a sequence of lines, with rou¬ 
tines to create, access, and delete char¬ 
acters, words, and lines. 

• The Input module reads and stores 
the original lines. 

• The Circular Shifter module pro¬ 
vides routines to access individual char¬ 
acters, words, and lines of the circular 
shifts of the stored lines. 

• The Alphabetizer module provides 
routines to access shifted lines in al¬ 
phabetical order. 

• The Output module prints the cir¬ 
cular shifts in alphabetical order. 

The top-level program first invokes 
the Input module, which stores the lines 
using the Line Storage module. The 
actual representation used by Line Stor¬ 
age is hidden from Input. Functions 
exported by the Circular Shifter mod¬ 
ule are then invoked. Circular Shifter 
retrieves the stored input using Line 
Storage, hiding decisions about data 
representation and algorithms from the 
top-level program. Then functions from 
the Alphabetizer module are used to 
sort the shifted data. Alphabetizer ac¬ 
cesses the data through Circular Shift¬ 
er, while hiding the sorting algorithm 
from the top-level program. Finally, 
the Output module accesses the sorted 
list using Alphabetizer (and perhaps 
Circular Shifter). In contrast to the com¬ 
mon functional decomposition, alter¬ 
native control structures are easy to 
construct. 

Potential changes in the context of 
Design 1. Parnas’s data decomposition 
is effective in handling such alternative 
representations and implementations 
as packed-versus-unpacked characters, 
explicit-versus-implicit representation 
of shifts, and monolithic-versus-incre- 
mental alphabetization. However, Par¬ 
nas’s decomposition does not directly 
support other kinds of enhancements. 
This is not surprising, since Parnas was 
concerned primarily with situations in 
which a system’s functional specifica¬ 
tions remained unchanged, although 
the implementations could vary. Look¬ 
ing at how some proposed enhance¬ 
ments might be supported in Parnas’s 
decomposition of KWIC demonstrates 
some evolution problems in systems 
modularized according to the principle 
of data abstraction. 

Consider augmenting KWIC with the 
capability to omit shifts that start with 


one of a set of noise words, such as 
articles. Parnas’s decomposition admits 
two approaches to this modification. 

The first one is to include a simple 
filter in the Output module (or add a 
small module that provides this filter). 
The filter checks the first word of each 
shift, printing the associated line only if 
it does not start with a forbidden word. 
This approach is straightforward but 
unnecessarily inefficient. In particular, 
all shifts must be alphabetized, includ¬ 
ing those that will ultimately be omitted 
from the output. This added cost can be 
significant, as can be seen by looking at 
the KWIC index for Unix manual en¬ 
tries, which is based on a one-line head¬ 
er associated with each Unix command. 
If this index listed all shifts, there would 
be about 5,000 entries. But the actual 
index omits shifts starting with about 
150 noise words: Only about 1,000 shifts 
actually appear when the noisy ones are 
filtered out. Sorting dominates the over¬ 
all cost. In this case, the cost is O (N lg 
N), where N is the initial number of 
entries, so this decrease in sortable en¬ 
tries saves at least a factor of five in 
execution time. This cost is indicative of 
the performance penalties that may be 
required by restricting access to encap¬ 
sulated data. 

The second approach to implement¬ 
ing the omit version of KWIC is to mod¬ 
ify the Circular Shifter. (The Alphabet¬ 
izer module could also be modified, but 
this approach is less attractive for simi¬ 
lar concerns about performance.) As 
each call is made to the Circular Shifter 
to insert a new line, the line is checked 
against the set of prohibited words. If a 
match is found, the line is not inserted 
into the shifted list. The code to imple¬ 
ment this approach is simple, and it 
keeps the structure of the shifter imple¬ 
mentation straightforward. However, as 
we shall see, this kind of solution be¬ 
comes complicated when further changes 
are considered. 

A second possible enhancement closely 
relates to the first: Given a set of words, 
include only those shifts that start with 
one of them. This approach might be 
used to cull a set of smaller KWIC indi¬ 
ces, each related to a subtopic. 

The same implementation approach¬ 
es are available, with the same trade¬ 
offs. Filtering is easy, leaving the exist¬ 
ing modules unchanged, but it is 
inefficient. Or the “include” check can 
be incorporated into the shifter, adding 
complexity to shifter code and raising 


the question of how to handle other 
shifter clients. 

In this small example, modifying the 
shifter is not a serious problem. Howev¬ 
er, including both omission and inclu¬ 
sion enhancements in the shifter makes 
the module more complex. Rewriting it 
from scratch might produce a clean ver¬ 
sion, but it’s not practical to rewrite a 
module each time an enhancement is 
made. So, in practice, module complex¬ 
ity tends to explode as repeated en¬ 
hancements are made. 

Two additional possible enhance¬ 
ments closely relate to the first two. In 
these, omission and inclusion are again 
provided, but on the original list of lines 
rather than on the shifts. These enhance¬ 
ments, when combined with the first 
two, help produce KWIC indexes that 
meet a wide range of needs. The same 
implementation trade-offs arise. Filter¬ 
ing can be done after the line storage is 
initialized, again at added cost (although 
not so bad as in the shifter’s case, since 
the insertion cost is linear). Or the Line 
Storage module itself can be modified, 
just as the shifter was. 

One problem with modifying the shift¬ 
er and line-storage modules as suggest¬ 
ed is that the decision to include a given 
line should not be the responsibility of 
those modules. This is not a serious 
problem for the simple enhancements 
we have discussed, but it becomes much 
more significant as other enhancements 
and modifications are introduced. For 
instance, what if a user wanted an en¬ 
hancement where individual words could 
be included or excluded, as opposed to 
including or omitting shifts that start 
with these words? Implementing such 
changes efficiently in the line-storage 
or shifting modules would make the 
implementations confusing. Also, the 
capability to reuse modules (such as 
Line Storage) for storing other lists of 
words (such as the noise words) would 
be compromised-because orthogonal 
enhancements might be needed for each 
list. In any case, module focus on line 
storage or shifting would fade, which is 
inappropriate because it compromises 
the separation of concerns. It should be 
possible to treat each enhancement as 
an independent unit, with the only in¬ 
teractions being through operations on 
the shared data structures. 

Design 2: Tool abstraction. In Design 
1 , the enhancements — while possible 
— are unnecessarily complicated. In 
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particular, it’s unfortunate that log¬ 
ically independent requirements are 
difficult to implement efficiently 
without intertwining logically inde¬ 
pendent implementations. For in¬ 
stance, deciding whether to include 
a shifted line should not affect the 
implementation of the shift module, 
but that’s the most effective imple¬ 
mentation in practice. Tool abstrac¬ 
tion, in contrast, allows each toolie 
to act as a (largely) independent 
entity that focuses on a single func¬ 
tion, decreasing the complexity of suc¬ 
cessive enhancements. 

With tool abstraction, the input, shift¬ 
ed, and alphabetized data are kept as 
shared (although still abstract) data 
structures. When a given toolie modi¬ 
fies the common data, other dependent 
toolies are invoked indirectly. This keeps 
each toolie clear of functionally unre¬ 
lated code. The shared data are still 
abstract because they are not “opened” 
completely. In particular, the physical 
representations are still hidden by the 
data-abstraction mechanisms. The func¬ 
tions on these shared data entities are, 
hov/ever, factored into toolies. In con¬ 
trast, traditional abstract data types com¬ 
bine these two concerns. 

Design 2 is based on a collection of 
toolies that manipulate shared buffers 
representing sequences of lines. The 



Figure 2. Toolies that share line-buffer and 
shiftcd-line abstract data structures. 


following toolies define the basic oper¬ 
ations of KWIC. Figure 2 illustrates their 
interaction. 

• The Input toolie creates a new in¬ 
stance of a shared buffer. It reads lines 
from the input file, inserting each suc¬ 
cessive line into the shared line buffer. 

• The Circular Shifter toolie creates 
another instance of a shared buffer to 
hold the shifted lines. It associates its 
action, in the sense of a daemon or 
active data, with the termination of the 
insert operation of the Input toolie. As 
each line is originally inserted, the shift¬ 
er is implicitly invoked to create the 
shifts for that line. The Circular Shifter 
is not concerned with the internals of 
the Input toolie but only with its regis¬ 
tered insert operation. (In practice, dif¬ 
ferent systems handle registration in 


Active data in object-oriented systems 


Many object-oriented programming 
languages support some form of 
event-driven control, which is often 
used to update gauges and dials in 
user interfaces. Sometimes the lan¬ 
guage itself provides a notation to as¬ 
sociate a method invocation with the 
changing value of an object’s instance 
variable. In other object-oriented lan¬ 
guages, event-driven control is provid¬ 
ed as a set of kernel facilities. In 
Smalltalk-80, 1 for example, the system 
maintains a list of dependent objects 
for each object. An object can send it¬ 
self the changed message, which 
causes an update message to be sent 
to each of its dependents. This mecha¬ 
nism underlies the Model-View-Con¬ 
troller paradigm 2 that drives many as¬ 
pects of Smalltalk’s user interface. 

Another approach is exemplified by 
Flavors, 3 where methods inherited 
from multiple ancestor superclasses 


are combined by invoking method frag¬ 
ments before and after the main meth¬ 
od. Most modern object-oriented data¬ 
bases also include some style of 
“trigger.” 
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different ways; see the sidebars for 
examples.) Alternatively, the shift 
creation code could be associated 
with the complete input buffer, rath¬ 
er than with single lines, and there¬ 
fore could be triggered when all 
input lines are inserted as the Input 
toolie signals completion. Thus, in 
~ this example at least, tool abstrac¬ 
tion is suited for defining incre¬ 
mental and batch computations. 
The input lines and the shifted lines 
are conceptually separate buffers. 
Changing between creating a new buffer 
and using the input buffer directly, or 
between using an explicit or an implicit 
representation of the shifts, can be done 
by redefining the Circular Shifter too¬ 
lie. This illustrates how toolies can aug¬ 
ment data as well as function. 

• The Alphabetizer toolie associates 
its action with the shared shift buffer. 
The Alphabetizer is triggered by the 
completion of shifter activities to sort 
lines in the buffer. In the case of an 
implicit shift buffer, this results in a 
coroutine interaction between the two 
toolies. Another shared buffer could 
be created to hold the alphabetized 
shifts, if desired, or the alphabetized 
buffer and the shift buffer could be 
equated to the same data structure. 
The sort could also be incremental, 
associating incremental insertions with 
the insertion of each shift into the shared 
shift buffer. 

• The Output toolie provides a dis¬ 
play scheme for printing the alphabet¬ 
ized shift buffer. 


The top-level program invokes In¬ 
put followed by Output. The actions 
of Input cause the Circular Shifter to 
execute, the shifter actions cause the 
Alphabetizer to execute, and Output 
simply accesses the sorted, shared buff¬ 
er. An alternative approach would be 
for Alphabetizer to trigger an event 
when it’s done sorting; Output would 
be invoked to print the results auto¬ 
matically. 

Potential changes in the context of 
Design 2. Enhancements are accom¬ 
modated more effectively and efficient¬ 
ly in this approach. Tool abstraction 
provides the capability to naturally de¬ 
fine multiple enhancements indepen¬ 
dently of existing code, while still pro¬ 
ducing programs that execute 
efficiently. 

An Omit toolie can be associated 
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Structure-oriented environments 


with the insert operation (provided by 
the original Input toolie) on the shared 
shift buffer. If the first word of the shift 
being inserted is in the set of noise words, 
the toolie aborts the insert (that is, the 
Omit toolie is triggered by the initiation 
of the insert operation rather than its 
termination). The code for programs 
that insert into the shift buffer need not 
be changed. The cooperation between 
these toolies and the Omit toolie is trig¬ 
gered implicitly by operations invoked 
on the shared data rather than on ex¬ 
plicit calls between operations. This 
eases evolution because multiple too¬ 
lies can be triggered by the same oper¬ 
ation without any changes to the trig¬ 
gering operation. The same approach 
holds for the Include toolie on the shift 
buffer. It also works for the Omit and 
Include toolies on the shared input buff¬ 
er. When the input and shift buffers are 
made explicit, separate toolies can be 
associated with each one. 

Discussion 

Tool abstraction relates to a variety 
of other concepts. 

Tool abstraction versus pipes. Too¬ 
lies are similar in intent to Unix pipes, 
which link together a preplanned se¬ 
quence of small functional units. Each 
unit in the pipeline takes as input the 
output produced by the previous unit; 
execution is triggered by the arrival of 
this input. Pipes are much more limited 
than toolies because pipes must be con¬ 
nected sequentially, while toolies share 
abstract data and are permitted to have 
much richer control interactions. A unit 
cannot react to operations on the data 
made by subsequent units in the pipe. 
Furthermore, in contrast to toolies, units 
connected by a pipe share only a single 
predefined data representation — a se¬ 
quence of characters—with no capabil¬ 
ity for shared data definitions. When 
this is not a suitable representation for 
the internal processing of a particular 
unit, the unit must parse its input from 
and unparse its output to the standard 
character stream form. In contrast, each 
bundle of toolies can define its own data 
representation, with later enhancements 
perhaps adding components to the data 
structure. 

These two restrictions do not pose a 
problem for the previously suggested 
enhancements to KWIC. For instance, 


These environments consist of a col¬ 
lection of toolies that share structured 
(as opposed to textual) representa¬ 
tions of program objects. Toolies in 
these environments typically share 
data represented as an attributed ab¬ 
stract syntax tree, whose form is de¬ 
fined by a grammar consisting of a col¬ 
lection of context-free productions. 

Toolies are usually associated with 
these shared abstract syntax trees in 
the form of action routines or attribute 
grammars. An action routine is a pro¬ 
cedure, associated with a production 
in a grammar, that defines the actions 
of some toolie on instances of that pro¬ 
duction. In the Gandalf system, 1 action 
routines are written in a special-pur¬ 
pose programming language called 
ARL (Action Routine Language), which 
is oriented toward manipulating ab¬ 
stract syntax trees. Each action routine 
is associated with an operation on an 
abstract syntax tree node (such as 
create or delete, which indicates when 
it should be invoked). An alternative to 
action routines is to associate a set of 
attribute equations with each produc¬ 
tion in the grammar, as done in the 
Synthesizer Generator. 2 

Roughly speaking, an attribute 
equation defines the value of an at¬ 
tribute of an abstract syntax tree node 
as a function of the attribute values of 


pipes are a natural (although not partic¬ 
ularly efficient) solution to omit/include 
on original/shifted lines. The input sim¬ 
ply streams through a pipelined sequence 
of sorters and filters, and more filters 
can always be inserted in the pipeline. 
In other situations with more complex 
interactions among functional units, 
pipes are inadequate. The trade-off is 
not simple. The restrictions on pipes 
can be viewed as a way of managing 
complexity, but with the restrictions 
comes a reduction in the kinds of sys¬ 
tems that are easy to build. 

Tool abstraction versus inheritance. 

Inheritance in object-oriented languag¬ 
es can be used to provide some aspects 
of tool abstraction. In particular, inher¬ 
itance is an especially good approach to 
extending abstract data types. In many 
cases, a subclass can provide additional 
operations on an existing data type with¬ 
out modifying the base type. 


adjacent nodes in the tree. Attribute 
equations determine a graph of data 
dependencies that can be used to in¬ 
crementally reevaluate attributes when 
an editing toolie changes the shared 
tree. 3 

In both approaches, control is event 
driven. In the first case, toolies written 
as action routines are automatically ac¬ 
tivated when data is manipulated by 
the operation associated with the rou¬ 
tine. In the second case, toolies written 
as attribute equations are automatically 
invoked when updates are made to the 
data on which the attribute values de¬ 
pend. Enhancement is simplified in 
both cases, since typically the new 
function can be added as new action 
routines or attribute equations that are 
logically distinct from the existing ones. 
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However, inheritance doesn’t provide 
all the features needed for tool abstrac¬ 
tion. The most notable exception is 
events. These can be added to object- 
oriented systems (as with the Smalltalk- 
80 Model-View-Controller 4 ), but inher¬ 
itance doesn’t do the job by itself. Also, 
when inheritance is used to achieve code 
sharing rather than behavior sharing, 
the relationship to tool abstraction is 
even less clear. Handling triggering ef¬ 
fectively is especially difficult. Perhaps 
more fundamentally, most object-ori¬ 
ented systems do not encourage pro¬ 
gramming in the paradigm of tool ab¬ 
straction, even when they provide many 
of the underlying mechanisms. 

Additionally, inheritance imposes a 
hierarchy on data abstractions. Toolies, 
in contrast, are equals. In particular, one 
could define a system that uses a subset 
of existing toolies, picking and choosing 
from desired functions. This is not 
straightforward with inheritance, where 
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Other systems 

The paradigms considered in previ¬ 
ous sidebars briefly sampled the kinds 
of systems based on tool abstraction. 
Other examples include monitors in the 
Domain Software Engineering Environ¬ 
ment, 1 views and rules in relational da¬ 
tabase systems, 2 - 3 some extensions to 
the Interface Description Language, 4 - 5 
and artificial intelligence blackboard 
architectures. 6 

One of the major goals of the 
RPDE3 software development environ¬ 
ment is “to support both the integration 
of tools constructed from many small 
fragments and the construction of tools 
that can be extended to process new 
types of data without source-code 
changes.” 7 The most significant limita¬ 
tion of RPDE3 with respect to tool ab¬ 
straction is its lack of event-driven tool 
invocation. Tool interleaving is instead 
carried out by using explicit message¬ 
passing and routing rules. 

The INC programming language has 
been developed for writing incremental 
computations. 8 INC is based on the ob¬ 
servation that “there are many problem 
domains that require repeating a com¬ 
putation many times, each time on 
slightly different data,” and the claim 


that the specialized techniques for effi¬ 
cient recomputation developed for such 
domains can be unified in a language- 
based solution. INC program components 
are thus tiny toolies, with event-driven in¬ 
tegration specified by a circuit graph of 
components. 

Even some systems that do not support 
tool abstraction take a similar approach 
with regard to opening up the representa¬ 
tion of data to a variety of computational 
entities. In Famos (Family of Operating 
Systems), for instance, different levels of 
virtual machines can share representa¬ 
tions of abstract data types by having a 
module extension “join” a module to ac¬ 
cess its internal representation. 9 
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selecting a subclass implies selecting the 
properties of its superclasses. 

Finally, inheritance can be viewed as 
a model for merging toolies into a cohe¬ 
sive system. This is the approach taken 
in the Meld language. 5 

Events. Our examples rely on using 
an event (or trigger) mechanism. The 
basic reason is that triggers allow great¬ 
er independence among toolies. 6 With¬ 
out triggers, toolies would be directly 
responsible for cooperatively manag¬ 
ing their collective control flow. This 
process might be simple at first but would 
become increasingly complicated as en¬ 
hancements were introduced. 

Triggering can be implemented as an 
implicit, underlying mechanism or as an 
explicit, programmer-level mechanism. 
In attribute grammar-based structure- 
oriented environments, for instance, de¬ 
signers of specific environments are un¬ 
aware of a triggering mechanism. They 
simply write the desired set of attribute 
equations. The same is true for spread¬ 
sheet users. But the underlying imple¬ 
mentation triggers incremental evalua¬ 


tion when values are updated by the 
user. In production systems, the pro¬ 
grammer is aware of how rules fire and 
must build systems based on these se¬ 
mantics. 

When triggering is used as an implicit 
mechanism, many difficulties are man¬ 
aged by the underlying system. Circular¬ 
ity, for instance, can be a serious prob¬ 
lem. Toolies can indirectly invoke 
themselves, producing an unbounded 
execution. Most attribute grammar and 
spreadsheet systems, however, check (ei¬ 
ther statically or dynamically) for such 
circularities, so their designers need not 
be overly concerned about circularities 
of an attribute grammar or a spread¬ 
sheet. In action routine-based structure- 
oriented environments, however, the 
programmer must be aware of this prob¬ 
lem. The difficulties of trigger-based 
programming can be significant. The ben¬ 
efits, however, are also significant. 
There is now a wealth of practical 
(although perhaps not systematically 
understood and documented) experience 
with trigger-based programming, from 
such domains as structure-oriented 
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environments, production systems, 
recent relational and object-oriented 
databases, object-oriented systems, and 
access-oriented programming (as in 
Loops 6 ). 

Efficiency. We have addressed sever¬ 
al dimensions of efficiency in this article. 

One dimension is the question of al¬ 
gorithmic complexity of the underlying 
system. Abstract data types, and their 
associated implementations, are gener¬ 
ally designed to efficiently support a set 
of operations. If the interface remains 
inviolate, it may no longer support new 
functions efficiently as the system 
evolves. In the example discussed in the 
introduction, checking for duplicates by 
using the simple enqueue/dequeue in¬ 
terface is an instance of this problem; 
the fixed interface makes what ought to 
be a constant-time operation into a lin¬ 
ear-time operation (in terms of the num¬ 
ber of invocations on the interface). In 
some cases, the complexity is the same, 
but the constant can increase signifi¬ 
cantly, which may not be acceptable in 
practical systems. 
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Another dimension is whether trig¬ 
gering mechanisms slow down systems 
too much. There are at least two issues 
here. First, designers have quite a bit of 
experience with triggering mechanisms 
in a wide variety of domains (see side- 
bars). Many realistic systems have been 
based on triggering mechanisms, so there 
seems to be no inherent hurdle to over¬ 
come. Second, any added costs would 
be a matter of a constant factor, since 
the operation would have to be invoked 
anyway. With triggers, it’s just a ques¬ 
tion of haggling about the price. This 
contrasts with the algorithmic dimen¬ 
sion, since restricted interfaces can slow 
programs down by greater-than-constant 
costs. 

Language issues. Parnas’s initial pa¬ 
per presented the notion of data ab¬ 
straction largely separate from language 
and implementation issues. In fact, data 
abstraction can be practiced without 
special language features if the program¬ 
mers are sufficiently disciplined. With 
tool abstraction, however, language and 
runtime support are necessary because 
implicit invocation of toolies eases in¬ 
cremental evolution. This is not a seri¬ 
ous problem, however, since the sys¬ 
tems described in the sidebars provide 
concrete evidence that tool abstraction 
can be efficiently realized (although 
perhaps in restricted domains). 


T here can be no absolute judg¬ 
ment about which criteria 
and integration mechanisms are 
best. A structuring technique that’s ap¬ 
propriate in one circumstance may be 
inappropriate in another. System struc¬ 
tures based on the functional decompo¬ 
sition criterion criticized by Parnas may 
be appropriate when physical data for¬ 
mats are unlikely to change, but new 
paths for processing existing data are 
expected as the system evolves. Witness 
the success of Unix pipes. On the other 
hand, decomposition based strictly on 
data abstraction may be appropriate 
when data representations are likely to 
change, but not when external interfac¬ 
es are also likely to change. Finally, as 
we have argued, composition by using 
tool abstraction is appropriate when a 
system evolves through enhancements 
to the function supported by existing 
data structures. 

Although our examples have been 
especially simple, functional enhance- 


Table 1. Instances of tool abstraction. 


System 

Shared Data 

Toolies 

Control Mechanism 

Spreadsheets 

2D matrix 

Equations 

Dependency analysis 

Structure-oriented 

environments 

Abstract syntax 
tree 

Action 

routines 

Operations 

Structure-oriented 

environments 

Abstract syntax 
tree 

Attribute 

equations 

Dependency 

analysis 

Production 

systems 

Working 

memory 

Rules 

Patterns and 
rule resolution 

Object-oriented 

systems 

Object base 

Methods 

Active values 


ment does happen in complex situa¬ 
tions. Consider the complexities that 
arise when basic telephone services are 
enhanced with such services as call for¬ 
warding and call waiting. For example, 
if call forwarding is turned on and the 
phone is in use, should the call-waiting 
tone sound when an incoming call ar¬ 
rives or should the call be forwarded? 
In each case, data from the same sen¬ 
sors must be processed, the same billing 
data updated, and so forth. While the 
message queue and KWIC examples 
could reasonably be reimplemented 
from scratch when an enhancement oc¬ 
curs, this is not feasible for most phone 
system features. Thus it becomes espe¬ 
cially important for the implementation 
of optional new telephone services to 
be as independent as possible of the 
implementation of plain old telephone 
services. 

Luckily, it’s not necessary to choose 
one abstraction paradigm over the oth¬ 
ers. This is partly because no hard bound¬ 
aries exist between these abstraction 
techniques. Parnas’s decomposition of 
KWIC based on data abstraction ap¬ 
pears very much like the functional de¬ 
composition. The difference is that his 
interfaces hide representations of data 
and other implementation decisions. 
Similarly, tool abstraction is not anti¬ 
thetical to abstract data types: Indeed, 
the data pool shared by a collection of 
toolies can itself be an abstract data 
type. Moreover, it’s reasonable to ex¬ 
pect that a collection of toolies would 
be bundled as an abstract data type that 
hides the details of a particular decom¬ 
position and that enhancements would 


be made by adding toolies to the bun¬ 
dle. The Meld language takes this ap¬ 
proach. 5 

What, then, is to be gained from all 
this? The abstraction paradigm or par¬ 
adigms that drive a system’s design 
should be chosen to reflect the system’s 
expected evolution. If functional en¬ 
hancements are expected to be the pri¬ 
mary form of change (as they are in most 
large systems), tool abstraction repre¬ 
sents a particularly attractive and realiz¬ 
able addition to existing approaches. 

This has ramifications for three class¬ 
es of software engineers. Language im¬ 
plemented need to incorporate tool- 
abstraction principles into new language 
designs and develop general implemen¬ 
tation techniques. Environment build¬ 
ers need to develop facilities that sup¬ 
port system design based on tool 
abstraction (and analysis, testing, and 
debugging aids that support adding new 
toolies to existing systems). Finally, sys¬ 
tem designers need to be aware of the 
tool-abstraction paradigm and actively 
seek a system that supports shared data 
and event-driven tool integration. As 
explained in the sidebars, many instances 
of tool abstraction are widely used (also 
see summary in Table 1). 

The tool-abstraction paradigm raises 
several interesting and difficult research 
problems. When multiple toolies react 
to the same event, ordering becomes an 
issue. There is also the potential prob¬ 
lem of circularities among the depen¬ 
dencies implied by toolie events. When 
events are a programming-level para¬ 
digm, how can toolie independence be 
retained while circularities are prevent- 
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ed? Another problem is how to handle 
lazy-versus-eager invocations of toolies. 
For applications concerned with meet¬ 
ing timing constraints, how can the time 
costs of indirect invocation be under¬ 
stood and managed? 

We have discussed toolies only in the 
context of the kinds of data structures 
typically encapsulated in abstract data 
types. But tool abstraction might sup¬ 
port events other than operations on 
shared data structures. For example, it 
should be possible to attach toolie invo¬ 
cation to lack of data (when or where 
data is expected) and other exceptional 
conditions, to timer interrupts and oth¬ 
er signals, and to events accessible only 
through polling some external entity 
(such as sockets and sensors). Because 
software systems involving these kinds 
of events are typically quite complex, 
the tool-abstraction paradigm should 
prove particularly fruitful. ■ 
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An Optimizing Compiler 
for an SPAP Architecture 
Using AI Tools 


Helnye Azaria and Adrian Dvir 
Ben-Gurion University of the Negev 


The proposed 
methodology allows 
users to efficiently 
bridge the gap between 
high-level language and 
low-level microcode 
when implementing 
intensive mathematical 
operations and 
manipulations 
algorithms. 


A dvances in VLSI technology over the past decade have made possible the 
I design of fast special-purpose numeric processors for integer and float- 
: ing-point calculations. These processors are used in a variety of dedicated 
architectures for specific real-time, intensive numeric tasks, including image 
processing and robotics. One of the problems that arises in existing systems is low 
overall system efficiency, caused by software overhead. This stems from the fact 
that although the execution of numeric operations is generally very fast, the 
relatively long execution time of the hand-shaking and driving routines significant¬ 
ly lowers overall system performance. The methodology frequently used to achieve 
such systems is to rewrite critical routines by a hand-optimized assembler. This 
process is tedious and time-consuming, especially for advanced and complex 
architectures. In this article, we will show that some of these difficulties can be 
alleviated by taking advantage of artificial intelligence tools, such as a rule-based 
system. 1 

Our objective was to develop a cost-effective solution for real-time intensive 
mathematical operations algorithms. In robotics, for example, it is well known that 
the problem of real-time control strategy is associated with a large number of 
manipulations and multiplications of matrices. Due to the complexity of the 
model, 2 ' 3 these types of operations are the bottleneck with regard to any real-time 
control algorithm. Hence, a real-time robot-arm-control problem was taken as a 
case study. In this application, the numerical computation requirements are about 
8 million floating-point operations per second (Mflops), which is far beyond the 
capabilities of commonly available low-cost microcomputer systems. Several 
dedicated architectures for real-time robot arm control have been proposed, 
including parallel processing and special-purpose VLSI design. 4 5 Parallel process¬ 
ing has several disadvantages, such as intensive hardware development require¬ 
ments and higher costs. Special VLSI design is very costly and is not justified in the 
present application. 

This article proposes the use of an optimized special-purpose array processor 
(SPAP) architecture for the numerical computation aspect and a host micropro- 
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Description of the tested source algorithm 


The tested algorithm is based mainly on the so-called in¬ 
verse dynamics problem. This problem in robotics is asso¬ 
ciated with the problem of computing the generalized forc¬ 
es in the joints required to produce a motion of the robot 
arm along a predesigned trajectory. 23 The present algo¬ 
rithm for the solution of the inverse dynamic problem is de¬ 
rived from the Lagrangian formulation. 3 The input variables 
of the algorithm are the positions of each degree of free¬ 
dom, namely, the variables 0„ /= 1, 2, ... , n, where n is 
the number of degrees of freedom. In the following consid¬ 
erations, we denote 9, by /(/), the derivatives 58,/Sf by dt{i) 
and the second derivative by ddt(i). In our application, n = 
6. The output results of the control algorithm are the n mo¬ 
ments for each link joint, denoted by f{i). The iterative con¬ 
trol algorithm, which consists of a recursive forward and 
backward computation process, is obtained by a collection 
of operations on matrices. 

The notation at(i) denotes AJ where the matrix A, has the 
form 2 ' 3 


sin a, sine, a, cos 9, 
-sina,cos9, a, sine, 
cos a, d, 

0 1 


where a,, a,, and d, are the parameters of the rth link joint that 
are constants for a specific robot arm, as other constants 
krm(i), kj(i), and kgt. The control symbols are not relevant and 
therefore are not explained. Variables vs(/), mvs(i), vc(i), and 
mvc(i) are used below to represent sin(0,), —sin(9), cos(9,), and 
-cos(8 ( ), respectively. Constants 0 and 1 are represented by kO 
and k 1. Then, for the considered robot arm, 2 the matrix AJ, for 
which a, = a, = d, = 0, is represented by 


at( 1) = 


vcl vsl kO k 0 
vmsl vcl kO kO 
kO kO kt kO 
kO kO kO kl 


In the accompanying tables, the notation R ,y w denotes matrix 
dimension lx m. For every iteration, the computation process 
consists of load operations, forward computation, backward 
computation, and store operations. The initialization of con¬ 
stants and matrix entries is detailed in Table A. The processor 
operations numbers for the studied SA computations process 
before and after the presented optimization are detailed in 
Table 1. 


Table A. Initialization of constants and matrix entries. 


Constants and Matrix Entries 

Dimension 


LOAD SCALAR [AcO, k 1, kml, k2] 

A? 1 


LOAD [krm (/)] 

A? 4 * 1 ; /= 1,2,.. 

. , n 

LOAD [kj (/)] 

A? 4 * 4 ; /- 1,2,.. 

■, n 

LOAD [kgf\ 

A? 1 * 4 


LOAD [af (/), dat(i), ddat(i)] 

A? 4 * 4 ; i - 1, 2, . . 

■ ’ n 


cessor for nonnumerical computation 
operations. 6 8 The type of problems that 
can be handled with the proposed con¬ 
figuration are those associated with the 
control of linear constant systems, 9 di¬ 
rect and inverse dynamic problems, and 
the direct and indirect kinematic prob¬ 
lems of a robot arm. 2 ' 4 These applica¬ 
tions have the following common fea¬ 
tures: 

•The algorithms are usually repre¬ 
sented in matrix notation, and the algo¬ 
rithm matrix calculations can be per¬ 
formed with only the four elementary 
mathematical operations (+, -, x, •*-). 

• The main part of an algorithm can 
be isolated into a well-defined module 
containing input variables and constants, 
a set of sequential matrix calculations, 
and output results. Hence, the isolated 
module permits concurrent operation 
of the array processor (AP) and the 
host microprocessor. 

• The calculation speed requirements 


can be obtained by a commercially avail¬ 
able floating-point unit (FPU), 1011 the 
central component of the AP. 6 - 7 

We achieve a cost-effective solution 
for these types of applications using the 
new optimization methodology the pro¬ 
posed optimizing compiler (OC) pro¬ 
vides. The goals of the OC include effi¬ 
cient compilation of the algorithm by 
optimizing mathematical operations and 
optimizing the hardware resources of 
its target architecture — in short, an 
optimized special-purpose AP. 


Advantages of the 
optimizing compiler 

Transforming a given mathematical 
expression into an AP microcode mem¬ 
ory format is a complex task that re¬ 
quires determining all instruction fields 


and managing local operand memory 
resources. A compiler does this better 
than an assembler, since translation of 
mathematical expressions into assem¬ 
bler language is a complex, tedious, time- 
consuming task prone to introducing 
errors. The simplest way to construct an 
AP compiler is to write a library of 
basic-operation subroutines (such as a 
matrix multiplication subroutine). In this 
case, the high-level language link is per¬ 
formed at the subroutine level. This 
approach is adopted by commercially 
available AP support software. An AP 
is usually supplied with an assembler 
and a routines library, to be called from 
a high-level language program. 7 - 8 
We have found that the software hand¬ 
shaking between a high-level language 
and an AP subroutine library and its 
hardware entails considerable overhead. 
A slow subroutines handshake wastes 
precious time when moving data be¬ 
tween the host main memory and the 
AP local memory. As a result, the aver- 
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age efficiency in a commercial AP is 
only about 30 percent. 8 A better ap¬ 
proach is to avoid the use of the subrou¬ 
tine library methodology and to com¬ 
pile the whole control algorithm 
separately using an efficient AP com¬ 
piler. 

The numerical efficiency of a tested 
source algorithm (SA) (see the descrip¬ 
tive sidebar) was first studied using an 
AP hardware simulator. Preliminary 
results have shown that in this type of 
algorithm (for robot arm control 2 ' 4 ) there 
is a large redundancy in calculation and 
movement of data due to the following 
general properties: 

• The matrices are repeatedly defined 
and transferred between the host and 
the AP before and after every matrix 
operation. 

• The matrices are often reorganized 
in different formats — operations that 
require many data-move and copy in¬ 
structions. 

• The matrices include a considerable 
number of constants, resulting in a high 
probability of operations between con¬ 
stants — for which the result is known 
and can be calculated in advance. 

• The same variables appear in differ¬ 
ent parts of the SA, resulting in a high 
probability of duplicate mathematical 
operations. 

• The multiple appearance of the same 
constants in different matrix locations 
results in a waste of data memory space. 

In light of the above considerations, 
it became clear that the matrix form of 


the studied algorithm, which is suitable 
for analytical presentation, is inefficient 
for numeric processing. It is estimated 
that by eliminating the redundancies 
associated with the above-listed prop¬ 
erties, more than 80 percent of the nu¬ 
merical operations can be eliminated 
and the data memory can be used more 
cost-effectively. However, hand trans¬ 
formation of the SA matrix notation 
(see the sidebar) to a more efficient 
notation seems to be an almost impossi¬ 
ble task, considering the large number 
of mathematical operations (more than 
8,000) and the complexity of the work. 

Development of the optimizing com¬ 
piler we propose is achievable and more 
desirable solution to the problems of 
handshake overhead and SA notation 
efficiency. The following design consid¬ 
erations were taken into account: 

•Optimization should occur at the 
algorithm level and not at the basic- 
operations level, as is usually the case 
with conventionally available commer¬ 
cial optimizing compilers. 

• To save memory space and opera¬ 
tion time, optimization should take ad¬ 
vantage of the inherent SA redundant 
computation, duplicate variables, and 
multiple appearance of the same con¬ 
stants. 

•The SA should not be translated 
into a sequence of basic numerical op¬ 
erations but into a symbolic notation, so 
that efficient optimization can be car¬ 
ried out. In fact, optimization applies a 
set of rules to a collection of mathemat¬ 
ical operations, as is possible with pen- 
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Figure 1. Source algorithm mathemat¬ 
ical operations, before and after. 


cil and paper, but in an automatic and 
efficient way. Taking advantage of AI 
science contributions, we can accom¬ 
plish this by means of an advanced logic 
programming tool, the rule-based sys¬ 
tem. 1 ' 12 

The section entitled “OC implemen¬ 
tation using AI tools” contains a de¬ 
tailed description of the OC, but here 
we evaluate one of the goals of the OC: 
the optimization of the number of mathe¬ 
matical operations of a source algorithm. 
The bar chart in Figure 1 illustrates the 
number of operations (before and after 
optimization) of a tested SA (see the 
sidebar). The overall number of 8,298 
mathematical operations (multiplica¬ 
tions, additions, subtractions, etc., as 
shown in Table 1) is reduced to 956. 


Table 1. Processor operation numbers for each iteration of the tested SA computation process. 


SA Operations 

SPAP Operations 







Addition 

Multiplication 

Subtraction 

Load 

Store 

Total 

Load f(i); dt(i); ddt(i); 

s(i); c(i)\ i = 1,.... 6 

— 

— 

— 

30 

— 

30 

Forward process 

2,736 

3,288 

— 

— 

— 

6,024 

Backward process 

1,028 

1,240 

6 

— 

— 

2,274 

Store/(i); i = 6,..., 1 

— 

— 

— 

— 

6 

6 

Total before 

optimization 

3,764 

4,528 

6 

30 

6 

8,334 

Total after 

optimization 

578 

378 

0 

30 

6 

992 

Optimization 

percentage 

85% 

92% 




88 % 
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Figure 2. Special- 
purpose array 
processor archi¬ 
tecture. 



Target architecture 

The target architecture of the OC is a 
special-purpose AP architecture for in¬ 
tensive numeric computations. The AP 
differs from conventional architectures 
mainly because of the parallelism of 
dataflow and the optimized instruction 
set. Conventional von Neumann archi¬ 
tecture is based on one memory unit 
using one address bus and one data bus, 
through which operational codes, oper¬ 
ands, and results are transferred sequen¬ 
tially between the processor and the 
memory. Multiple machine cycles and 
memory accesses are needed to com¬ 
plete one floating-point instruction. The 
AP contains several buses that operate 
in parallel, enabling a floating-point in¬ 
struction to be executed in a single ma¬ 
chine cycle. The FPU, the main element 
in the AP, is a dedicated VLSI device 
for fast floating-point calculations. Com¬ 
pared to a conventional large-instruc¬ 
tion-set microprocessor, the FPU has 
only a limited number of mathematical 
operations, permitting fast hardwired 
implementation of single-clock-cycle 
instructions (as in a RISC machine). 
Commercially available FPUs from sev¬ 
eral manufacturers have a calculation 
capability of up to 100 Mflops. 1011 

The special-purpose AP architecture, 
designed for this study as the target 
architecture, is optimized for robot-arm- 
control algorithms. Attached to a host 
(such as a PC), the proposed SPAP ar¬ 
chitecture (see Figure 2) features three 
main components: the microcode mem¬ 
ory, the operand memory, and the FPU. 
These components are optimized from 
the hardware resource’s point of view, 
using advanced logic programming tech¬ 


niques. Development of this optimiza¬ 
tion procedure is one of the objectives 
of the present study., In addition, the 
SPAP architecture 

•constitutes, from the architectural 
point of view, a single complex instruc¬ 
tion execution unit, with input and out¬ 
put operands; 

• loads the local operand memory and 
microcode memory separately; 

•contains four operation modes: 
download microcode memory, down¬ 
load SPAP input data, execute micro¬ 
code operation, and upload SPAP out¬ 
put data; and 

• includes only four opcodes for the 
mathematical operations (+, x, +) and 
has no branch or loop instructions (which 
are not required for the straightforward 
execution of control algorithms). 

Moreover, 

• The microcode word has four fields: 
an opcode field and three operand ad¬ 
dress fields. 

• The operand address points to the 
local operand memory space. 

• The local operand memory is multi- 
ported, permitting overlapping of three 
operand accesses: fetching two oper¬ 
ands and storing the previous result, 
using three separate buses (A, B, and C 
in Figure 2). 

When applying the proposed new 
methodology to algorithms, the optimi¬ 
zation process (detailed in the next sec¬ 
tion) automatically reduces the number 
of mathematical operations. This part 
of the optimization — the SA optimiza¬ 
tion (see the next section)—is architec¬ 
ture independent, in spite of the fact it 


reduces the amount of microcode mem¬ 
ory required in the SPAP. Moreover, 
the OC also permits optimization of 
other components of its target architec¬ 
ture: the operand memory and the FPU. 
This part of the optimization (see the 
section entitled “Optimization of hard¬ 
ware requirements”) is architecture 
dependent. 


OC implementation 
using AI tools 

Artificial intelligence is the branch of 
computer science that deals with sym¬ 
bolic, nonalgorithmic methods of solv¬ 
ing problems associated with the use of 
heuristic rules. The knowledge-based 
expert system is one aspect of AI. A 
knowledge base contains both declara¬ 
tive knowledge (facts about objects, 
events, and situations) and procedural 
knowledge (information about courses 
of action). Among the most prevalent 
knowledge representation techniques 
used in expert systems is the rule-based- 
system approach. In a rule-based sys¬ 
tem, procedural knowledge in the form 
of if-then rules is integrated with de¬ 
clarative knowledge. 1 

An important and helpful tool in AI 
programming is logic programming, 
which is based on machine-independent 
abstract concepts: truth and logical de¬ 
duction. A logic program is a set of 
logical axioms or rules defining rela¬ 
tionships between objects. The compu¬ 
tation of a logic program is the deduc¬ 
tion of consequences of the program. 

A basic technique of using logic pro¬ 
grams is defining logical databases. 112 A 
logical database comprises a set of facts 
and rules (basic statements of a logic 
program); the data structures manipu¬ 
lated by logic programs are logical terms. 
Facts are a means of defining the rela¬ 
tionship between objects. If, during its 
achievement as a logical goal (I/O, pro¬ 
gram manipulation), the knowledge has 
a side effect, the name predicate is used. 
Rules are a means of defining complex 
relational queries using other simple 
relationships, with reference to the da¬ 
tabase. 

Prolog (the abbreviation for program¬ 
ming in logic) is a well-known advanced 
logic programming language. 12 A Pro¬ 
log program gives the computer a de¬ 
scription of the problem using a number 
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IFD = {ifd[s]}; s 6 5 (2) 



Figure 3. Optimizing-compiler modules. 


of facts and rules, and then 
asks the computer to find all 
possible solutions. This 
means that, given the neces¬ 
sary facts and rules, Prolog 
uses deductive reasoning to 
solve programming prob¬ 
lems for declarative languag¬ 
es. In procedural languages, 
the programmer must tell the 
computer exactly how to per¬ 
form its tasks. Once the Pro¬ 
log programmer has de¬ 
scribed what must be 
computed, the Prolog sys¬ 
tem itself organizes how that 
computation is carried out. 

The OC is implemented 
by means of a rule-based 
system written in Prolog. 
Optimization includes sev¬ 
eral steps and encompasses 
about 200 rules; it also in¬ 
cludes different stages that 
are combined and carried out 
in a complex way to satisfy 
the implementation con¬ 
straints (compilation time 
and memory space limita¬ 
tions). For the sake of clarity, the opti¬ 
mization principles are explained by 
dividing the optimization process into 
four modules (see Figure 3): SA defini¬ 
tion and transformation, SA optimiza¬ 
tion, hardware optimization, and mi¬ 
crocode translation. 

The input to the OC is the SA infor¬ 
mation, which includes 

(1) definition of the SA inputs; 

(2) definition of the SA operations 
given in compact matrix notation; 
and 

(3) definition of SA outputs. 

The output of the OC is an optimized 
microcode for the SPAP architecture. 

S A definition and transformation. The 

SA input information is declared by the 
definition of the S A inputs and the trans¬ 
formation of the SA matrices, as well as 
by operations between matrices into a 
uniform database. The transformation 
process necessitates the use of tempo¬ 
rary array pointers (TAPs) to keep track 
of the relationship between the matrix 
elements and the uniform database no¬ 
tation. This is done by the first module, 
which includes four procedures: SA def¬ 
inition, S A transformation, temporary da¬ 
tabase definition, SA results definition. 


Input facts definition. The SA inputs 
(variables, v, and constants, k) are de¬ 
clared and given valid Prolog symbolic 
names. The inputs are classified in sev¬ 
en different symbolic types. Let us de¬ 
fine the group S to include these types: 

S = {fcO, kml, kl, (km(value)}, 
jk(value)), 

{vm(name)), (1) 

(v(name)}}; s e S 

where 

kO represents constant zero (0) 
kml represents constant minus one 
(- 1 ) 

kl represents constant one (1) 
km(value) represents other input neg¬ 
ative constant excluding -1, identi¬ 
fied by its value 

k(value) represents other input posi¬ 
tive constant excluding 0 and 1, iden¬ 
tified by its value 

vm(name) represents input negative 
variables, identified by their name 
v(name) represents input positive 
variables, identified by their name 

All the S A operands’ inputs are defined 
as facts ifd in a Prolog database; hence, 
these SA ifd elements are defined as the 
database input facts definition (IFD): 


For example: ifd[vcl], 
ifd[vsl], ifd[/fc9.18],. . . (vcl, 
vsl, and 9.18 are two vari¬ 
ables and a constant used in 
SA) (see the sidebar). 

Transformation of SA op¬ 
erations. The SA operations, 
originally given in mathemat¬ 
ical notations, are trans¬ 
formed as facts into a Prolog 
uniform symbolic format da¬ 
tabase by means of pseudocal¬ 
culations. The transformation 
is implemented by means of a 
set of predicates; each predi¬ 
cate is dedicated to a specific 
basic mathematical operation. 
A database of symbolic ele¬ 
ments is produced for each 
calculation. Every symbolic 
element represents a symbolic 
microcode (sm) to be stored 
in the microcode hardware, 
and each sm contains three 
symbolic operand address 
fields and an opcode (opc). 

For example, an SA calculation c = a 
* b is translated into a database element 
sm(c, a, *, b)\ therefore 4x4 matrix 
multiplication will be translated into 
112 sm database elements (for each of 
the 16 elements of the result matrix, 
seven calculations are needed — four 
multiplications and three additions — 
for 112 calculations (16 x 7)). 

Let us define OPC as the group of 
basic mathematical operations 

OPC = {+, -, *, +}; opc G OPC 

and define an operation as the symbolic 
microcode 

sm p = [c p , a p , opc, b p }\ a p , b p , e S (3) 
where 

a p ,b p represents the sm p input sym¬ 
bolic operands. 

a p g IFD or (a p = c,; q <p) 
b p g IFD or (b p - c q \ q< p) 
p,q = operation sequential 
numbers 

c p represents the sm p result symbolic 
operand. 

Every c p , which is a partial result ob¬ 
tained during transformation of the SA 
operations, receives a new symbolic 
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Figure 5. Matrix multiplication trans¬ 
formation. 


name, using the above-defined types 
(see Equation 1). For example 

sm = {v[name2],,/cml, *, v[namel]} 

This notation represents the mathemat¬ 
ical operation 

v[name2] = (-1) * v[namel] 

Let us define the SA partial results as 
the group C 

C = [c p ]; c p e S', C n IFD = {<(>}; 
p = l,2,...,N i 

The following point is important: A 
uniform symbolic format is required to 
carry out the logical algorithm optimi¬ 
zation. Therefore, there should be no 


symbol duplications, and all the partial 
results are assigned different symbol 
names. 

The result of the SA operation trans¬ 
formation is the nonoptimized symbol¬ 
ic microcode database, defined as SM: 

SM = {[sm,]}; p = 1, 2,..., N, (4) 

The SA operations are translated into a 
Prolog database as facts; for example, 

sm{v[ name3], v(cl), *, kml], 
represents: [name3] = cl * (-1) 
sm{v[name5], vra[name4], +, 
vm(sl)}, represents: [name5] 
= -[name4] 

+ (~sl) 

Temporary database definition for 
array pointers. Since SA inputs are of¬ 
ten repeated in several different matrix 
definitions, a mechanism for removing 
duplicate inputs is essential for the op¬ 
timization. For every input duplicate 
definition, a temporary array pointer is 
defined rather than an IFD element. 
Every reference to the pointer symbol 
is redirected to the appropriate IFD 
symbol or the existing partial result c p . 

Let us define a temporary array point¬ 
er (tap) 

tap = (arn, i, acp}; acp € S (5) 
and all the tap as the group TAP 
TAP = {{tap*}); w = 1, 2,... , N 2 (6) 
where 

arn represents an SA array name, 
i, j represent the array indexes, and 
acp represents a symbol that exists 
elsewhere as an input in IFD or as a 
c p in SM. 

The temporary array pointers are used 
for definition of the inputs matrix and 
for building the microcode database SM. 
For example 

• The A ! matrix definition requires 16 
taps to point to the relevant elements in 
the IFD (see Figure 4). 

• A matrix multiplication transforma¬ 
tion requires the array pointers of the 
two 4x4 matrices, stores the operations 
as 112 sm p elements in SM (see Equa¬ 
tions 3 and 4), and creates 16 new tap 
elements in TAP (see Equations 5 and 
6 ) for further references (see Figure 5). 


To save compilation memory spaces, 
the temporary array pointers are delet¬ 
ed from the database as soon as they are 
no longer used (during the SA opera¬ 
tion transformation). At the end of the 
first module compilation, only those that 
point to the S A final results are needed. 

Results facts definition. Let us define 
a final-result variable of the SA as a fact 
res[f] in a Prolog database. These facts 
define the S A outputs for the OC; hence, 
these SA final results are defined as the 
database results facts definition (RFD). 

RFD = {res[/]};/€ 5 (7) 

The same symbolic names that ap¬ 
pear as Cp in the SM elements (see Equa¬ 
tion 3) performing the final results must 
be used as/in RFD. The RFD has an 
important role in the elimination of 
operations with unused partial results, 
as explained below. 

In summary, the output of the first 
module of the optimization process is 
the Prolog database that includes IFD, 
SM, RFD (see Figure 6). 

SA optimization. This module in¬ 
cludes three procedures that use rule- 
based subsystems and Prolog predicates 
(see Figure 7). 

Elimination of unnecessary operations. 
The number of elements in the SM da¬ 
tabase is reduced by eliminating unnec¬ 
essary operations, such as an operation 
with a known result. For example, if a p 
and b p operands are constants in an 
operation sm p , the result can be calcu¬ 
lated in advance and added to the data¬ 
base IFD as a new constant input. In our 
case study, 196 cases of unnecessary 
operations were found. A rule-based 
subsystem was then used to search for 
these cases in the SM database. Once an 
operation sm p is eliminated, its known 
partial result symbol c p is replaced by a 
pointer cp in all the other sm q (q > p), 
where c p appears as operand a q or b q . 
The replacement is performed by means 
of a temporary pointer defined as 

tp = [c p , cp); c p , cp e S (8) 

The created pointers are defined as the 
secondary database TP: 

TP = [{tp d }Y, d = 1,2 . N 3 

Based on the above-described consid- 
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erations, the format of the optimi¬ 
zation rules for deleting unneces¬ 
sary operations is defined as 

unor ={tm p , rm, tp d , nk)\ 
tm p , rm e SM 

tp d e TP; nk 6 IFD; (9) 

p = 1,2. N{, 

d = l,2,...,N 3 

where 

tm p represents the input opera¬ 
tion to be tested when c p is its 
partial result 

rm represents the operation re¬ 
sult, where rm = tm p (if the test¬ 
ed operation is necessary) or 
{♦} 

tp d represents a created pointer 
if the tested operation is un¬ 
necessary, where tp d = {c p , sym¬ 
bol of known result) or {<)>}. 
nk represents a new constant to be 
added to the IFD database, or {4>} 

For example 

(1) unor, = {[c p , k x , *, k y ), {<()}, { c p , /q), 

{*<}} 

In this case, an operation between two 
constants is eliminated during the com¬ 
pilation time by adding a precalculated 
constant ( k z = k x * k y ) to the IFD data¬ 
base and creating a new pointer tp d in 
the secondary database TP. This point¬ 
er points to the result c p , the value of 
which is the calculated constant k z in 
IFD. If the value k z already exists, the 
new pointer is redirected to the existing 
value. 

(2) unor 2 = [{c p , k x , +, v x ], [c p , k x , +, v x ), 

W. M) 

Here, the operation between a constant 
k x and a variable v„ is necessary, no new 
pointer is created in TP, and no con¬ 
stant is added to IFD. 

(3) unor 3 = {{c p , - v x , +, vj, {<f>}, {c p , 0), 

m 

In this case, the result of the operation 
(+) between the variables (v x ) and (-v x ) 
is known (0), the operation is eliminat¬ 
ed, and a new pointer is created in TP 
that points to the existing value 0 in 
IFD. 

Overall, 49 similar rules are identi- 



Figure 6. First optimization module. 



Figure 7. Second optimization mod¬ 
ule. 


fied for each mathematical operation, 
for a total of 196 rules. 

UNOR = {{unor,}); r = 1,2,..., 

196 

The UNOR rule-based subsystem 
operates on the SM database. 

Elimination of equivalent operations. 
The next step is to eliminate repetitive 
or equivalent operations. For each op¬ 


eration sm q , q = 2,..., IV,, a search 
is carried out to detect similar pre¬ 
vious operations sm p ,p < q. A search 
and recognition of equivalent op¬ 
erations is also conducted by a rule- 
based subsystem. The format for 
the optimization rules for eliminat¬ 
ing equivalent operations is defined 


eor = [tm q , em p , rm, tp d )\ 

P<<1\ 

tm q , em p , rm e SM; (10) 
tp d e TP; p = 1,2,, A!,; 
d * 1,2. N 3 

where 


tm q represents the input operation 
to be tested; 

em p represents a previous existing 
operation equivalent to the 
tested operation; 

rm represents the result operation, 
where rm = tm q (if the tested opera¬ 
tion is necessary) or {(()}; and 

tp d represents a created pointer if the 
tested operation is unnecessary, 
where tp d = [c q , c p ] or {()>) 

For example, 

eor, = [{c q , v x , *, v y ], [c p , v y , *, v x ), (0), 
Kc p )\ 

In this case, the tm q (c, = v x * v y ) 
operation is eliminated and a new pointer 
is set for c q that points to the result c p of 
the equivalent operation em p (c p = v y * 
v x ). Based on the above-described con¬ 
siderations, 14 eor rules were identified. 

EOR = {{eor,)}; t= 1,2,..., 14 

The EOR rule-based subsystem oper¬ 
ates on the SM database. 

Elimination of operations leading to 
surplus results. In several robot-arm- 
control algorithms, there are many cas¬ 
es in which a considerable number of 
partial results are not used. 

An unneeded operation sm p is de¬ 
fined as any operation whose c p result 
does not appear in any other successive 
operation sm q , q>p (as input operands 
a q or b q ) and which is not a final result 
res[f] of the S A. For example, when a cp 
that is a variable v(name) is multiplied 
by zero (/c0) in a sm q operation (q > p) 
and is not further used, all previous 
calculations that lead to v(name) could 
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operand_memory_allocation:- 
nm (I, Cl, _,_,_), 
nm(J,CJ, _), (/>/) 

nm (K, AK, BAT), (/ > tf), (A: > J), (AK = CJ or BK = CP), 
nm (L, _AL, _BL), (L > K), not (AL = CJ or BL = CL), 
replace_symbol (/, C/, C7). 
operand_memory_allocation. 
replace_symbol (/, Cl, CJ):- 
nm ( K, C/, /lAT, OPCA:, BA - ), (AT > /), 
retract (nm (K, Cl, AK, OPCK, BK)), 
assertz (nm (K, CJ, AK, OPCK, BK)). 
replace_symbol (I, Cl, CJ):- 
nm (K, CK, Cl, OPCK, BK,), (K> = I), 
retract (nm (K, CK, Cl, OPCK, BK)), 
assertz (nm (K, CK, CJ, OPCK, BK)). 
rep!ace_symbol (I, Cl, CJ):- 
nm (K, CK, AK, OPCK, Cl,), (K > = 1), 
retract (nm (K, CK, AK, OPCK, Cl)). 
assertz (nm (K, CK, A K, OPCK, CJ)). 
replace_symbol(_, _). 


Figure 8. Optimization predicate for operand memory allocation. (Note: I, K, 
L, and J are sequential numbers given to the SM database prior to this optimi¬ 
zation stage.) 


be eliminated. In Prolog, this can be 
accomplished by a simple predicate 

cancel_not_used_used-c:- 
sm(C, A, Opc, B), 
not(jm(_, C_, _)), 
not(sm(_, _, _, C)), 
not(res(C)), 

retract(sm(C, A, Opc, B)). 
cancel_not_used_c 

However, this simple predicate was 
found to be very time-consuming and 
similar work was undertaken to find a 
faster predicate. We found that a better 
process for locating all the unneeded 
instructions is to start from the last op¬ 
eration and scan the SM database back¬ 
wards twice, in a tree recursive manner 
— each time for one operand: 

cancel_not_used_c_recursively(C):- 
sm(C, A, Opc, B), 
not(sm(_, C, _, _)), 

not (sm(_,_,_, C)),not(res(C)), 
retract(sm(C, A, Opc, B)), 
cancel_not_used_c_recursively(A), 
cancel_not_used_c_recursively(B). 
cancel_not_used_c_recursively(_). 

In this way, the unneeded operations 
are located first. This process even de¬ 
tects input variables that do not con¬ 
tribute to the final results. 


Optimization of hardware require¬ 
ments. The rules and predicates given 
above contribute to the optimization of 
the SPAP microcode memory space. 
However, this is only a partial hardware 
optimization. For a cost-effective de¬ 
sign, optimization of the other main 
components of the SPAP — the local 
operands memory and the FPU — is 
required (see Figure 2). This is the ob¬ 
jective of the third module (see Figure 
3). It should be noted that this addition¬ 
al optimization cannot be done by the 
second module of the SA optimization. 
The S A optimization can be carried out 
only if each partial result is assigned a 
different symbol. This is a prerequisite 
for the logical optimization procedure 
detailed in the section entitled “Trans¬ 
formation of SA operations” (see the 
remark in italics on p. 44). This con¬ 
straint is removed once the SA optimi¬ 
zation is completed; an operand memo¬ 
ry location can be assigned more than 
once. 

Optimization of operands’ memory 
allocation. The SM database is further 
subjected to optimizing rules that reas¬ 
sign operands’ memory locations once 
their content is no longer used. This 
way, the memory space needed for the 
whole calculation is significantly re¬ 
duced. The reduction is very important 


because the cost of fast multiport mem¬ 
ory is relatively high and makes a signif¬ 
icant contribution to SPAP cost. The 
added, rather complicated, optimiza¬ 
tion rule is given in principle as follows: 

For every sm„ (i= 1,2...) find sm p (j 
> i) in which c, is used for the last 
time as operand a ; or as b r If such 
sm, is found, replace notation c t by c, 
in sm, and in every other sm p , (p > j) 
where it appears as a p or b p . 

In other words, the operand memory 
location that first contains c, can be 
reused for storing the sm, result c jt if c, is 
no longer needed. By this process, the 
same memory location is shared by a 
number of partial results. For further 
details, see the Prolog list in Figure 8. 

FPU internal registers requirements 
optimization. The second hardware op¬ 
timization considered is an efficient use 
of the FPU internal registers. This is 
accomplished by eliminating unneces¬ 
sary transfers between FPU internal 
registers and operands memory. Un¬ 
necessary transfers include results used 
in the consecutive instruction only. This 
optimization is especially useful for 
multiply and accumulate operations used 
in matrix multiplication, where many 
local results are not needed after the 
consecutive operation. This procedure 
was found to further reduce the number 
of operand memory locations needed. 
In some APs, it can also reduce compu¬ 
tation time. 

Microcode translation. The output list 
of the optimization process is a discrete 
notation of the optimized SA, which 
includes a list of numeric operations 
performed on symbolic variables and 
constants. This optimized SM database 
is easily translated from a symbolic for¬ 
mat to the specific SPAP hardware mi¬ 
crocode format by means of simple line- 
by-line basic translation. Each jm, 
element is translated to an SPAP micro¬ 
code memory word. The c„ a„ and ft, are 
translated to locations in the local oper¬ 
and memory. The mathematical opera¬ 
tion (opc) is translated to FPU opcodes. 
The optimized SM microcode database 
is hence translated to a binary data file, 
ready to be downloaded to the micro¬ 
code memory of the SPAP. The IFD 
database is also translated into a binary 
data file of numerical values for down¬ 
loading to the local memory of the SPAP. 
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The RFD database is used for the defi¬ 
nition of result locations in the upload 
binary data file. 


Results and discussion 


When applying the proposed new 
optimization methodology to the con¬ 
trol algorithm 3 for a robot arm with six 
degrees of freedom (see the sidebar), 
the overall number of mathematical 
operations is reduced by 88 percent, as 
the bar chart shows (see Figure 1). Of 
that amount, about 85 percent and 92 
percent savings are in the addition and 
multiplication operations, respectively 
(see Table 1). Figure 9 describes the 
performance of the second optimiza¬ 
tion process module (see Figure 7) of 
the OC applied to the source algorithm. 
The UNOR rules (see Equation 9), the 
EOR rules (see Equation 10), and the 
predicate (see the section entitled “Elim¬ 
ination of operations leading to surplus 
results”) enable the diminution of 80 
percent, 2 percent, and 6 percent of the 
total SA operations, respectively. The 
very large reduction in the required 
mathematical operations is evidently due 
to the fact that the robot-arm-control 
algorithm is based on matrices that in¬ 
clude a large number of constants, many 
of them Is, -Is, and Os (see the sidebar). 
Furthermore, the few variables of the 
control system appear in many loca¬ 
tions in the matrices. Elimination of 
unnecessary and repetitive calculations, 
such as multiplication by 0,1, or -1 or 
calculation between constants (for which 
the results are known beforehand), could 
have been sorted out in different heu¬ 
ristic ways. Neuman and Murry 2 evi¬ 
dently did this for similar algorithms to 
obtain the dynamic equations. Howev¬ 
er, our proposed methodology is fully 
automatic and could be easily adapted 
to other optimization tasks. Moreover, 
the proposed new approach also deals 
with the problem of automatic transla¬ 
tion of the optimized database to an 
optimized microcode for a special-pur¬ 
pose architecture. Interestingly, there 
is good agreement between our optimi¬ 
zation results and those of Neuman and 
Murry, 2 although the parent robot-arm- 
control algorithms in the two cases are 
not exactly the same. 

Aside from the robot-arm-control 
problem, the proposed optimization 



Figure 9. Source algorithm optimiza¬ 
tion performance. 


scheme can be useful in many other 
control applications. For example, con¬ 
sider the classic problem of solving the 
outputs in a multi-input, multi-output 
linear system driven by a given input 
vector-valued function. When the sys¬ 
tem is given in its Jordan-form, 6 the 
system’s matrices incorporate many 1 
and 0 entries. Thus, applying the ap¬ 
proach and methodology described in 
this study will lead to a considerable 
reduction in the required computation 
time, permitting achievement of real¬ 
time control with relatively low compu¬ 
tational power hardware. 

In robotics, the problem of real-time- 
control strategy is also associated with a 
large number of matrix multiplications. 
The matrices involved are derived from 
the homogeneous transformation. 2 ' 3 ' 9 
Accomplishment of the forward and 
backward recursive parts of the algo¬ 
rithm of the inverse dynamics problem 
is thus obtained by performing a se¬ 
quence of matrix multiplications of 
sparse matrices (that is, matrices with a 
high percentage of 0 — and 1 — en¬ 
tries). Application of the proposed new 
optimization methodology in these cas¬ 
es will thus be highly effective. For ex¬ 
ample, test runs on the multiplication of 
six homogeneous transformations of 
Leung and Shanblatt, called the direct 
kinematic solution (DKS), 5 have shown 
that the number of operations is re¬ 
duced from 560 to 108, an optimization 
efficiency of about 83 percent. 


W e believe four fundamen¬ 
tal conclusions can be de¬ 
duced from this investiga¬ 
tion. They are: 

(1) An OC, using a rule-based system 
as presented here, can drastically re¬ 
duce the number of mathematical oper¬ 
ations and relax hardware specifications, 
thereby reducing the software overhead 
and the overall cost of implemented 
systems. 

(2) Intensive numerical algorithms 
should be treated at the highest possi¬ 
ble level and not in small modules at the 
basic level of mathematical operations. 
Therefore, best results are obtained 
when the whole algorithm is optimized 
and compiled in one process. 

(3) Although the optimization pro¬ 
cess was tested on a specific robot-con¬ 
trol algorithm (seethe sidebar), the same 
methodology can be applied to other 


control algorithms or other general in¬ 
tensive numerical algorithms. Optimi¬ 
zation will be especially effective when 
the algorithm is characterized by a set 
of matrix operations where the matri¬ 
ces incorporate many constants as en¬ 
tries and few variables that repeatedly 
appear in different parts of the algo¬ 
rithm. 

(4) Robot-arm-control algorithms 
have been studied for many years. Sev¬ 
eral improvements have been proposed 
to reduce computation complexity by 
analytical manipulation of the algorithm. 
The compact matrix representation of 
algorithms, as is usually used in robot 
arm control, is very inefficient when 
directly translated to numerical compu¬ 
tation. Our study proposes a methodol¬ 
ogy for even greater reduction of the 
number of mathematical operations by 
means of the proposed optimization 
methodology. Consequently, the opti¬ 
mized algorithm is represented not as a 
set of equations but as a list of elemen¬ 
tary operations that can be easily trans¬ 
lated into microcode for given architec¬ 
tures. 

This work demonstrates the potential 
contribution of the fast-growing AI dis¬ 
cipline to applied research problems. 
The research objective was to develop a 
cost-effective solution to existing inten¬ 
sive mathematical operations algorithm 
problems. Positive results were obtained 
by combining experience and knowl¬ 
edge of three scientific areas: computer 
architecture, robotics, and AI. To the 
best of our knowledge, the proposed 
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approach has never been considered in 
robot-arm-control research. 

A major benefit of using the AI ap¬ 
proach is the modularity and expand¬ 
ability of the rule-based system. 112 Ad¬ 
ditional rules can easily be incorporated 
to suit a given algorithm. For example, 
an additional rule using Prolog predi¬ 
cates can be added to transform a sum 
of products of the form 

(a * ft]) + (a * b 2 ) + .. . + (a * b„) 
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to the form 

a * (ft, + b 2 + b 3 + . . 7 + b n ) 
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Architectural Support for 
Designing Fault-Tolerant 
Open Distributed Systems 


Salim Hariri and Alok Choudhary, Syracuse University 
Behcet Sarikaya, Bilkent University 


A distributed voting 
algorithm and a two- 
level hierarchy for 
permanent memory are 
key elements in this 
scheme for supporting 
fault tolerance in open 
distributed systems. 


A distributed system consists of autonomous computing modules that inter- 
I act with each other using messages. Designing distributed systems is more 
difficult than designing centralized systems for several reasons. Physical 
separation and the use of heterogeneous computers complicate interprocessor 
communication, management of resources, synchronization of cooperating activ¬ 
ities, and maintenance of consistency among multiple copies of information. The 
main advantages of distributed systems include increased fault-tolerance capabil¬ 
ities through the inherent redundancy of resources, improved performance by 
concurrently executing a single task on several computing modules, resource 
sharing, and the ability to adapt to a changing environment (extensibility). 1 

Distributed systems cover a wide range of applications. Recent advances in 
VLSI devices and network technology will further increase the use of distributed 
systems. As the complexity of these systems increases, so does the probability of 
component failure, which can adversely affect the performance and usefulness of 
such systems. Thus, reliability, availability, and fault tolerance become important 
design issues in distributed systems. Fault tolerance is the system’s ability to 
continue executing despite the occurrence of failures. Increasing the reliability and 
fault tolerance of a system involves a trade-off between the cost of failure (for 
example, costs incurred by incomplete or incorrect computations) and the cost of 
incorporating redundancy and recovery mechanisms. 

Because of their inherent redundancy, distributed systems provide a cost- 
effective way to apply fault-tolerance techniques. Open distributed systems pro¬ 
vide universal connectivities among their components because their designs are 
based on the standard protocols adopted by the International Standards Organi¬ 
zation (ISO). In this computing environment, interacting processes communicate 
through messages that traverse a stack of software layers. Consequently, applying 
fault-tolerance techniques to execute critical tasks can be costly in terms of 
execution time. 

In this article, we first provide an overview of the main techniques for designing 
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fault-tolerant software and hard¬ 
ware systems. We identify the 
important features of the build¬ 
ing blocks (computers, memo¬ 
ries, buses, etc.) that can sup¬ 
port an efficient implementation 
of fault-tolerant open distribut¬ 
ed systems (FTODS). Taking 
into account the features of these 
building blocks, we propose an 
organization for FTODS. In 
FTODS, the algorithms needed 
for transferring files and syn¬ 
chronizing the concurrent activ¬ 
ities of the computing modules 
— and for recovery — are ISO 
standard protocols. We propose 
the use of low-level voting and 
recovery algorithms that can run 
as a layer of software above the 
operating system to make the 
open distributed system an at¬ 
tractive environment for apply¬ 
ing fault-tolerant techniques. 

Design 

considerations for 
fault tolerance 

Fault tolerance, a system’s ability to 
continue executing its tasks despite the 
occurrence of failures, can be achieved 
by fault masking. Masking (also called 
static redundancy) is incorporated into 


Glossary of acronyms 

AAT — Atomic action tree 

ACSE — Association control service element 

ASE — Application service element 

CCR — Commitment, concurrency, and recovery 

DVA — Distributed voting algorithm 

FTAM — File transfer and management 

FTMP — Fault-tolerant multiprocessor 

FTODS — Fault-tolerant open distributed systems 

HPM — Hierarchical permanent memory 

JTM — Job transfer and manipulation 

MPM — Magnetic permanent memory 

MTTF — Mean time to failure 

ODP — Open distributed processing 

ODS — Open distributed systems 

OSI — Open Systems Interconnection 

RDA — Remote database access 

SIFT — Software-implemented fault tolerance 

SPM — Semiconductor permanent memory 

TP — Transaction processing 

TR — Transaction reliability 

VTP — Virtual terminal protocol 


the design to concurrently mask faults 
and prevent their propagation to other 
modules. The most common example of 
static redundancy is the triple modular 
redundant system. Another approach 
for providing fault tolerance is dynamic 
redundancy, which uses spare compo¬ 
nents to replace faulty modules once 
they are detected. Still another approach 
— a combination of these two, called 


hybrid redundancy — applies 
static and dynamic redundancy 
to achieve fault tolerance. In 
general, the design of a fault- 
tolerant computer involves one 
or more of the following strate¬ 
gies: fault masking, fault detec¬ 
tion, fault containment, fault 
diagnosis, repair/reconfigura¬ 
tion, and fault recovery 2 (see 
the sidebar “Strategies for de¬ 
signing fault-tolerant comput¬ 
ers”). 

Designing a fault-tolerant dis¬ 
tributed system is more involved 
than designing a fault-tolerant 
centralized system. Two main 
problems must be addressed 
during design: 

(1) Concurrency control, 
which involves scheduling con¬ 
current execution of tasks on 
different nodes such that their 
results are identical to a serial 
execution of the tasks (serializ- 
ability requirement). 

(2) Redundancy management, which 
involves preserving consistency among 
replicated resources and maintaining 
the state information with backup mod¬ 
ules to support recovery. 

Transactions are an important pro¬ 
gramming paradigm for simplifying the 
design of reliable distributed applica- 


Strategies for designing fault-tolerant computers 


Many techniques have been used to build fault-tolerant 
computers. They include 

Fault masking: Concurrent masking and correction of gen¬ 
erated errors. 

Fault detection: Use of hardware and software mechanisms 
to determine the occurrence of a failure. Fault detection 
mechanisms include concurrent fault detection, stepwise com¬ 
parison, and periodic testing to determine whether computers 
or communication links are operating correctly. 

Fault containment: Prevents propagation of erroneous or 
damaged information in the system after a fault occurs and 
before it is detected. 

Fault diagnosis: Locates and identifies the faulty module re¬ 
sponsible for a detected error. 

Repair/reconfiguration: Eliminates or replaces the faulty 
module, or provides means to bypass it. 

Fault recovery: Corrects the system to a state acceptable 
for continued operation. 

Most of these techniques have been used to build such 
computers as the Tandem 16 NonStop system, the Stratus 


computer system, the VAXft 3000, the Teradata and Sequoia 
systems, the fault-tolerant multiprocessor (FTMP), the soft¬ 
ware-implemented fault-tolerance (SIFT) system, and AT&T’s 
Electronic Switch System (ESS). 12 The effectiveness of fault- 
tolerance techniques can be measured by the “coverage,” de¬ 
fined as the conditional probability of recovering from a fault 
once it occurs. 3 It is difficult to measure this parameter be¬ 
cause it involves evaluating the probability that fault detec¬ 
tion, fault diagnosis, repair/reconfiguration, and recovery al¬ 
gorithms are operating correctly. 
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Transactions 


A transaction can be defined a; 
three properties': 


a collection of operations having the following 


Permanence: The results of committed transactions will not be lost. 

Serializability: The results of executing transactions concurrently are the same 
as if they were executed serially. 

Use of the transaction concept to model distributed computations provides a 
convenient means to solve the concurrency control and redundancy management 
problems. 1 The concurrency control problem consists of three tasks: assigning an 
order to all transactions, identifying conflicting transactions, and synchronizing 
transactions to resolve the identified conflicts. Basically, there are three ap¬ 
proaches to concurrency control: time-stamp-based schemes, locking protocols, 
and optimistic techniques. 2 
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tions (see the “Transactions” sidebar). 
Techniques for managing redundancy 
and maintaining consistency of repli¬ 
cated objects are broadly character¬ 
ized as centralized- and decentralized- 
control algorithms. The centralized- 
control approach supports strong con¬ 
sistency requirements and prevents 
deadlocks, but it is susceptible to single 
points of failure. The decentralized-con- 
trol approach supports weak 
consistency requirements 
(when it is permissible to 
have the state of some rep¬ 
lica out of date for a short 
period of time), and there¬ 
fore it can potentially in¬ 
crease a system’s through¬ 
put. The primary-copy 
algorithm 3 applies the cen- 
tralized-control strategy to 
ensure the consistency of 
replicated resources. In this 
scheme, one node is desig¬ 
nated as the primary node 
and made responsible for 
serializing updates. When 
the update values have been 
computed, the primary node 
broadcasts them to all oth¬ 
er nodes in the system. The 
primary node then waits to 
receive acknowledgments 


from all nodes before processing the 
next transaction. The main problem with 
this scheme is that it permits no paral¬ 
lelism among transaction executions. 

Voting algorithms have also been used 
to ensure consistency of replicated re¬ 
sources. In this scheme, managers of 
replicated resources use a common set 
of rules to determine whether an up¬ 
date can be made. The algorithm’s con- 
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Session and other layers 


Figure 1. The structure of an application layer 


trol can be centralized or decentralized, 
depending on whether the voting is done 
at one site or multiple sites. 3 In addition 
to maintaining consistency of replicat¬ 
ed resources, redundancy management 
is responsible for system recovery in the 
presence of node crashes and communi¬ 
cation link failures. 


Open distributed 
systems 


In this article, we investigate tech¬ 
niques for providing architectural sup¬ 
port to improve the execution of dis¬ 
tributed applications that use the Open 
Systems Interconnection standards. The 
main goal of the OSI reference model is 
to provide universal connectivity among 
heterogeneous computers. The refer¬ 
ence model is designed to structure com¬ 
munication hardware and software in a 
layered architecture. 4 ISO committees 
are working on an architecture in line 
with the reference model for open dis¬ 
tributed processing (ODP). This effort 
aims to combine the OSI model with a 
database model to arrive at a global 
framework for designing distributed 
systems. In such an environment, any 
computer would be open for communi¬ 
cation and could be integrated easily 
with the existing distributed systems to 
perform certain tasks. Implementation 
of the communication protocols as lay¬ 
ered software tends to be very slow and 
consequently limits the scope of appli¬ 
cations for open distribut¬ 
ed systems. 

The application layer is 
implemented as several ap¬ 
plication service elements 
(ASEs), with one ASE 
serving them all. This ele¬ 
ment is called the associa¬ 
tion control service element 
(ACSE), and it provides 
association (connection) es¬ 
tablishment/disconnection 
service to other ASEs. In 
open distributed systems, 
distributed applications are 
implemented by the servic¬ 
es that the ASEs provide. 
The application layer ser¬ 
vices can be in the form of 
file transfers using the 
FTAM (file transfer and 
management) protocol, re¬ 
mote database access using 
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the RDA protocol, job transfers using 
the JTM (job transfer and manipula¬ 
tion) protocol, a virtual terminal using 
the VT protocol, and transaction pro¬ 
cessing using the TP protocol. 

To achieve reliable and fault-tolerant 
computing in open distributed systems, 
the ASEs use the commitment, concur¬ 
rency, and recovery (CCR) services pro¬ 
vided by a special ASE called the CCR 
protocol. 4 CCR is a standard two-phase 
commit protocol that provides the ser¬ 
vices needed to achieve concurrency 
control and recovery during execution 
of application layer tasks such as FTAM, 
TP, VTP, etc. Figure 1 shows the OSI 


communication model and the interac¬ 
tions among the ASEs of the applica¬ 
tion layer. 

Architectural support 
for FTODS 

In this section we identify features 
that should be supported by the com¬ 
puting modules of open distributed sys¬ 
tems to facilitate an efficient implemen¬ 
tation of fault-tolerant algorithms. On 
the basis of this criteria, we propose an 
organization for fault-tolerant open dis¬ 


tributed systems, the architecture of its 
building blocks, and the required algo¬ 
rithms and protocols. The architecture 
of the computing modules should sup¬ 
port reliable broadcasting, self-repair/ 
recovery, selective fault tolerance, and 
permanent memory (see the sidebar 
“FTODS computing module capabili¬ 
ties”). 

Organization of the FTODS. An 

FTODS comprises a set of computing 
modules we refer to as nodes. Nodes 
communicate and interact with each 
other by broadcasting their messages 
on a redundant broadcast medium. A 


FTODS computing module capabilities 


The architecture of the computing modules should facilitate 
the efficient implementation of fault-tolerant algorithms. This 
architectural support can be provided by the following capa¬ 
bilities: 

Reliable broadcasting. Reliable broadcasting provides 
means for a set of processes to communicate in spite of fail¬ 
ures and is used frequently as a primitive operation to imple¬ 
ment reliable distributed applications. 1 It has been shown that 
reliable broadcasting provides an efficient solution to many 
problems — for example, distributed consensus, distributed 
synchronization, replicated update, and transaction manage¬ 
ment in database systems. 2 Furthermore, these reliable pro¬ 
tocols will run efficiently on the underlying architecture if its 
communication network has a broadcast capability. 

Self-repair/recovery. Recovery in distributed systems with 
replicated resources, computations, and database systems is 
a nontrivial task. Moreover, the overhead of recovery can de¬ 
grade system performance significantly. 2 Hardware recovery 
blocks have been proposed to reduce overhead during the 
save operations of system state and to speed up recovery 
when faults are detected in a multiprocessor system. 3 The lit¬ 
erature is rich with techniques that can be used to support 
self-repair and recovery. For example, the use of static re¬ 
dundancy to achieve fault masking has been used in the 
c.vmp (computer-voted multiprocessor) computer. 4 Also, Kuhl 
and Reddy 5 have addressed fault diagnosis at the system 
level and the conditions under which nodes can diagnose the 
failure of other nodes to achieve self-test. 

The architecture of the computing modules should support 
a hierarchical approach for recovery such that most of the 
time-consuming tasks are executed at a lower level of this hi¬ 
erarchy. The use of static (masking) redundancy and diag¬ 
nostic routines simplifies the tasks involved in fault detection, 
self-reconfiguration and repair, and recovery. Providing the 
computing modules with these features could significantly re¬ 
duce the complexity of recovery at the application level. With 
the proliferation of VLSI chips, I/O processors, controllers, 
and memory, it is now reasonable to use redundant compo¬ 
nents in designing the computing modules. 

Selective fault tolerance. Since not all task operations re¬ 
quire fault tolerance, it is desirable to run only the critical op¬ 


erations in a fault-tolerant mode and the rest in a normal 
mode. This will lead to a significant improvement in perfor¬ 
mance without compromising the fault-tolerance require¬ 
ments. Consequently, the architecture of the computing mod¬ 
ules should support dynamic reconfiguration such that the 
processors within a node can be configured for use as a 
masking redundancy during critical operations and as a multi¬ 
processor system during noncritical operations. This capabili¬ 
ty has been supported by the c.vmp, which contains three 
processor-memory pairs that can operate independently and 
can also provide fault-tolerant operations. 4 

Hierarchical permanent memory system. Most recovery 
algorithms needed to achieve fault-tolerant computing rely on 
permanent storage. 1 Stable storage is used to store the 
checkpoints of a system state; these checkpoints will be used 
to restore the system to the previous fault-free checkpoint 
state when a failure occurs during normal operation. Stable 
storage is normally constructed using dual magnetic disks. 
Performance of fault-tolerant algorithms can be improved sig¬ 
nificantly if stable storage is implemented in a two-level hier¬ 
archy in which semiconductor permanent memory is used in 
the first level and magnetic permanent memory is used in the 
second. The SPM acts as a buffer between the processor 
and the MPM. 
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Figure 2. Organization of the fault-tolerant open distributed system. 



set of nodes forms a cluster. A cluster 
(C,) communicates with another cluster 
(C y ) through the gateway associated with 
each cluster (see Figure 2). 

Node architecture. Each node has sev¬ 
eral processing elements which can be 
configured dynamically to form either a 
redundant computing module or a 
shared-bus multiprocessor system. The 
processing elements communicate with 
each other via a redundant node bus. 
Components of a node (as shown in 
Figure 3) include a general-purpose 
microprocessor, an input/output system, 
and bus controller subsystems. The num¬ 
ber of processing elements needed at 
each node depends on the reliability 
and fault-tolerance requirements. A 
node has two operational modes: fault 
tolerant and multiprocessing. For non- 
critical tasks, a node’s processors can be 
configured as a shared-bus multipro¬ 
cessor system. For critical tasks, the 
node’s processors execute the same task 
synchronously and use a voting proce¬ 
dure to mask out the effect of faulty 
processors. The coordinator processor 
( P c ), which is chosen from the set of 
fault-free processors according to a pre¬ 
defined selection procedure, supervises 
the voting algorithm and communica¬ 
tion with other nodes. 

Hierarchical permanent memory. Per¬ 
manent memory provides secure data 
storage for the state of a node and any 
other information relevant to the exe¬ 
cution of a transaction. Consequently, 
it is possible to commit the transaction 
atomically or undo all its actions should 
that transaction be aborted. Permanent 
memory can be implemented using mag¬ 
netic or semiconductor technology. Fig¬ 
ure 4 shows the organization of the hier¬ 
archical permanent memory (HPM), 
which uses a semiconductor permanent 
memory (SPM) at the first level and 
magnetic permanent memory (MPM) 
at the second level. The SPM contains 
two battery-backup RAM units, a com¬ 
parator unit, and several bus interface 
units. The MPM consists of dual mag¬ 
netic disks and a comparator. 

In the proposed HPM, the SPM acts 
as a buffer between the coordinator pro¬ 
cessor of a node and the MPM; as a 
result, the HPM unit’s effective access 
time is reduced. The coordinator pro¬ 
cessor of a node updates the SPM atom¬ 
ically according to the following proce¬ 
dure: 
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Figure 4. Hierarchical permanent memory. 


(1) After obtaining a majority con¬ 
sensus on the data to be committed, the 
coordinator processor places the data 
on the node bus with a write signal. 

(2) The values from the bus are writ¬ 
ten into the two semiconductor memo¬ 
ries simultaneously. 

(3) The comparator module immedi¬ 
ately reads back and compares the up¬ 
dated locations. 

(4) If the values differ, an abort sig¬ 
nal is sent to the coordinator processor 
via the node bus indicating that the 
values need to be rewritten. This pro¬ 
cess can be repeated up to a predefined 
number of times before an error signal 
is generated. If the comparison opera¬ 
tion produces a match, then the updat¬ 
ed values are committed and an appro¬ 
priate signal is sent to the coordinator 
processor. 

Figure 5 is a flowchart describing an 
atomic write operation. Error detection 
and correction codes can also be used to 
increase the reliability and simplify the 
diagnosis of the memory system. How¬ 
ever, coding techniques alone cannot 
provide fault tolerance against crashes 
of memory devices. A similar proce¬ 
dure is used for a read operation. In 
addition to the fault-tolerance capabil¬ 
ity hierarchical permanent memory pro¬ 
vides, its use also improves the perfor¬ 
mance of recovery protocols. 

Cluster coordinator and gateway. For 
each set of nodes forming a cluster (C,), 
there is a node designated as the cluster 
coordinator (C r ). The nodes of a cluster 
are ordered in a predetermined priority 
list so that any fault-free node knows 
the procedure for selecting the C c node. 
The C c node periodically receives status 
messages from the nodes in its cluster. 
Also, the C c supervises the recovery 
procedure when one of its nodes is in a 
crashed state. A cluster’s gateway for¬ 
wards all messages routed to nonlocal 
nodes through the gateways connected 
to the intercluster communication link. 
The remote gateways pick up the mes¬ 
sages addressed to one of their nodes. 

Selective fault-tolerance capability. 
Redundancy and fault-tolerant algo¬ 
rithms are used to ensure atomic execu¬ 
tion of critical tasks and system recov¬ 
ery when faults occur. For example, 
updating a bank account is a critical 
task, and its execution should be con¬ 
trolled by a commit protocol. In this 


case, the critical operations are those 
that update the bank accounts. Howev¬ 
er, there are other operations that do 
not affect the system consistency re¬ 
quirements (reading a set of records, 
searching the database, etc.), so they do 
not need a commit protocol to control 
their execution. 

Since critical operations constitute 
only a small part of all the operations, 
redundancy in the architecture can be 
exploited to improve performance 
through parallel processing. However, 
for a node to operate in two modes — 
redundant mode and multiprocessing 
mode—the system should provide tech¬ 
niques for reconfiguration. 

Support for two processing modes is 
provided by monitors. A monitor is a 
layer of software embedded above the 
operating system. The tasks are repre¬ 
sented using a graph whose nodes rep¬ 
resent computational structures and 
whose arcs represent the dependency 
constraints between the computations. 
Critical tasks are distinguished from 
noncritical tasks using system primitives 
and semantics of the computation. The 
monitor maintains a queue of ready tasks 
that can be executed concurrently as 
soon as a processor is available. The 
monitor schedules the tasks in a first-in, 
first-out manner. However, scheduling 



Commit 


Figure 5. An atomic write operation. 


must incorporate execution of critical 
tasks, since they require all the proces¬ 
sors on a node. 

Two scheduling schemes can be used 
for scheduling critical tasks. The first 
uses preemptive scheduling in which a 
critical task to be scheduled preempts 
all other tasks. When the monitor rec- 
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ognizes that the next task is critical, it 
preempts the tasks on other processors. 
In the second scheme, the monitor waits 
for all current tasks to complete before 
scheduling a critical task, and it does 
not schedule any noncritical tasks dur¬ 
ing that period, even if processors are 
available. The first scheme has the ad¬ 
vantage that critical tasks are complet¬ 
ed as soon as possible. But the overhead 
of preempting tasks can be significant 
because the state of all the current pro¬ 
cesses must be saved. The second scheme 
does not require saving the states of the 
current processes, but the processors 
may remain idle for a long period, re¬ 
ducing utilization and throughput. 

Distributed voting algorithm. In our 
analysis, we assume that a faulty pro¬ 


cessor either stops producing data (fail- 
stop model) or produces corrupted data 
that the voting algorithm can recognize 
and use as a symptom of a faulty proces¬ 
sor. Processor faults can be caused by a 
malfunction of its hardware and/or soft¬ 
ware. A processor can assume only two 
states: faulty or fault free. During the 
fault-tolerance mode of operation, a 
node’s processors are configured to ex¬ 
ecute the same task (static redundancy) 
and the system memory is reconfigured 
as a hierarchical permanent memory. A 
coordinator processor ( P c ) is associated 
with each node. The P c supervises the 
distributed voting algorithm and com¬ 
mits the tasks’ execution. Selection of 
the P c follows a predefined procedure. 
For example, if each processor is identi¬ 
fied by a number (ID), then P c can be 


selected as the fault-free processor with 
the maximum ID value. 

Figure 6 describes the voting algo¬ 
rithm and related procedures for distrib¬ 
uted voting in the FTODS environment. 
Each processor P, computes a result (or 
a set of results) that must be voted on 
before it can be committed. The func¬ 
tions used to compute these results de¬ 
pend on the application transactions. In 
phase 1, these results are computed and 
each P , participating in the distributed 
computation broadcasts its results on 
the node bus using the broadcast primi¬ 
tive. Phase 2 involves voting on the re¬ 
sult and determines whether the result 
can be committed. Each P, receives the 
values from all other P’s and indepen¬ 
dently determines the confidence in the 
values by comparing them. 


Phase 1: 

Each P, in a node does the following, (1 < i < n) 

1. vote = function (“parameters”) /*computation depends on the application*/ 

2. broadcast (“node”, vote, P_name) /*broadcast “vote” to all processors (P_name) in “node”*/ 

Phase 2: 

/♦Each P, does the following, (1 < i < n)*l 

vote[/] = recv_msg (P ; , vote, P_name) 1 Hj<n,j * i /*rec, vote from all processors*/ 

If (votej/j = vote[/'j) V (J . 1 < i,j < n 
begin 

result = votefi]; /*result contains vote to be committed*/ 
vote commit (“all”); /*vote commit with param “all”*/ 
end; 

else if (vote[/j = vote[/]) for at least k votes s.t. k >\n!2\ 
begin 

result = vote of majority; /*result contains value of the majority*/ 
if ((P, = P t .) .and. (vote[i] * result)) /*if current coordinator not in majority*/ 
select_coordinator (P k e majority); /*select new coordinator*/ 
vote_commit (“majority”); /*commit the majority value*/ 

if (P, = Pc) 

local_recovery (for all P, not in majority); /*start recovery of processors not in majority*/ 

end; 

else /*no majority */ 
begin 

P, (status) = local_diagnostic (PJ, 1 < i < n /*start local diagnostics*/ 
if (P, (status) = “okay”) 
begin 

select_coordinator (“node”); /*select new coordinator from “okay” processors*/ 
if (P, = PJ /*new coordinator does the following*/ 
vote_commit (new_majority); /*commit new majority*/ 

end; 

else if (P, (status) * “okay”) V,, 1 &i & n /*a!l processors have failed*/ 
print (“complete node failure, external recovery required”); 

end. 


Figure 6. The distributed voting algorithm. 
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There can be three possible outcomes 
of this comparison. First, all values match 
with each other — a complete consen¬ 
sus. In this case, the coordinator proces¬ 
sor P c broadcasts the result to all P’s. 
Each P, acknowledges by sending a 
broadcast acknowledge message, and 
the result is written in the permanent 
memory. 

In the second outcome, only a major¬ 
ity is obtained on the result and the 
values of some P’s do not agree with 
that of the majority. In this case, there 
are two groups of processors, those be¬ 
longing to the majority and those that 
don’t. Since a majority is sufficient to 
commit a new value, the distributed 
voting algorithm (D V A) is executed such 
that it uses the majority result as the 
correct one. If the current coordinator 
is part of the majority, it coordinates the 
current DVA and initiates a recovery 
procedure for the P’s in the minority. If 
the current coordinator is not in the 


majority, then the P’s belonging to the 
majority select a new coordinator using 
the “select_coordQ” procedure. This 
new coordinator now coordinates com¬ 
mit and recovery for the minority pro¬ 
cessors. 

In the third outcome, a majority is not 
obtained. This triggers the “self-diag- 
nostic()” procedure associated with each 
P,. The self-diagnostic procedure returns 
the status of each processor as either 
“okay” or “failed” (actually, obtaining 
anything other than “okay” implies 
“failed”). If none of the processors re¬ 
turn a status “okay,” the node (all n 
processors in the node) is considered 
“failed.” This requires external recov¬ 
ery, which the cluster coordinator will 
perform as part of the distributed node 
recovery algorithm. If some P’s are okay 
after the self-diagnostic procedure, they 
broadcast their status and then select a 
new coordinator from this new set. Vot¬ 
ing is repeated for the new set, and the 


recovery procedure is initiated for oth¬ 
er P’s. 

Distributed node recovery algorithm. 
One node is designated as the cluster 
coordinator (C c ) for each cluster. Selec¬ 
tion of the C c follows a predefined pro¬ 
cedure similar to that used in selecting 
the P c of a node. 

Figure 7 describes the distributed node 
recovery algorithm. Each P c of a node 
periodically broadcasts a status mes¬ 
sage on the local broadcast medium. 
The current C c checks the status of all 
node coordinators. If any node is crashed 
and does not send a status message to 
the C c , the C c copies the state of that 
node as well as the node’s task_queue. 
It then assigns these tasks to other nodes 
in the cluster, choosing nodes with the 
minimum load. If a node that crashed 
earlier has recovered and sends an 
“okay” message to the C c , the C c up¬ 
dates its own record to reflect this 


Each Pc , (node coordinator) in a cluster does the following, (1 < i < m) 

Forever do /♦periodically*/ 

broadcast (“cluster”, status, P c ) /*broadcast “status” to all node coordinators in the cluster*/ 

/*The cluster coordinator is one of the node coordinators*/ 

recv_msg (Pc r status, P_name) 1 <j<m,j*i /* rec. status from all node coordinators*/ 

If (Pc, = C c ) /*if I am the cluster coordinator*/ 
begin 

For (/' = 1 to m) do /*check status of all nodes*/ 

If (status ( Pc, ) * “okay”)' /*any failed node?*/ 
begin 

state = Read (Pc,, state_block) /*read the state of Pc, from its HPM*/ 
task_queue = Read (Pc„ task_queue) /*Obtain the tasks of Pc,*/ 

PCj = select (minload, cluster) /*choose a node with minimum load currently*/ 

Send (Pc,, state) /*copy state of crashed node to the chosen node*/ 

Send (Pc,, task_queue) /*assign tasks to the new node*/ 
rec_status (Pc,) = failed /*record this with C*l 

recover (Pc,) /*recover the crashed node by copying updated information*/ 

/♦this recovery may not always be possible if the failed node’s hardware needs to be replaced (i.e., if catastrophic 
failure occurred)*/ 

end; 

else if ((status (Pc,) = okay) .and. (rec_status (Pc,) - failed)) l*Pc, was repaired but record was not*/ 
rec_status (Pc,) = okay /*update C, record*/ 

end; 

else if (Pc, * C c ) /*if I am not the cluster coordinator*/ 
if (status (C c ) * “okay”) /*the cluster coordinator failed*/ 
select_cluster_coordinator(); /*select new cluster coordinator*/ 

end. 


Figure 7. The distributed node recovery algorithm. 
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Procedure vote_commit (parameter: set_processor); 

/*set_processor: a list of processors that are fault-free, e.g. all, majority etc.*/ 
if (P, = P c ) /*if I am the coordinator*/ 
begin 

broadcast (“set_processor”, result, P_name); /*reliable broadcast result to processors in “set_processor”*/ 
k = II set_processor II; /*cardinality of set_processor*/ 
for / — 1 to A: 

recv_msg (P t e set_processor, bcast_ack, P_name); /*rcv. acknowledgment from processor in 
set_processor*/ 
exit; 
end; 

else if ((P, * P c ) .and. (P, e set_processor)) /*other than coordinator processor*/ 
begin 

recv_msg (P c , result, P_name); /*rec. result from coordinator*/ 
bcast_ack (P r , P„name); /*acknowledge to the coordinator*/ 
end; 
return; 

end vote_commit. 

Procedure select_coordinator (parameter: set_processor); 
if (my_node (status) = “okay”) 
begin 

broadcast (set_processor, status, P_name); /*broadcast status*/ 
recv_msg (set_processor, status, P_name); /*rec. status from other processor*/ 
if (my_node = max (set_processor)) /*e.g. largest node_id */ 
mynode = P c ; /*! am new coordinator*/ 

end; 

return; 

end select_coordinator 


Figure 8. Some procedures used in the distributed voting algorithm. 


change. If other node coordinators do 
not receive a status message from the 
C c , that is, if the C c itself failed, then 
node coordinators select a new C c fol¬ 
lowing a procedure similar to that for 
selecting a node coordinator (see Fig¬ 
ure 8). Once a new C c is selected, it 
repeats the above procedure to check 
for node failures. 

Implementation issues. The architec¬ 
tural support provided by the comput¬ 
ing modules of fault-tolerant open dis¬ 
tributed systems supports the trend 
toward open distributed systems. In 
FTODS, each computing module of a 
node has its own operating system and a 
runtime system that includes the dis¬ 
tributed voting algorithm, the distribut¬ 
ed node recovery algorithm, and the 
monitor (to schedule tasks and switch 
them between the two modes of opera¬ 
tion, and to do other housekeeping 
tasks). The fault-tolerance, concurren¬ 
cy control, and redundancy management 


algorithms use standard protocols and 
are implemented at the application lay¬ 
er as application service elements. In 
this environment, development of reli¬ 
able applications is significantly easier 
because they are not concerned with 
implementing the fault-tolerance, con¬ 
currency, and recovery techniques; these 
techniques are provided to the applica¬ 
tions as services by an ASE such as the 
CCR protocol. 

We can better understand this archi¬ 
tectural support by studying the main 
steps incurred during execution of a 
standard two-phase commit protocol 
(such as the CCR protocol). For exam¬ 
ple, to execute a transaction atomically, 
the master node running this transac¬ 
tion broadcasts a message (C-Begin) to 
all nodes involved in the transaction 
execution, indicating the beginning of 
an atomic execution. Since the underly¬ 
ing communication structure of FTODS 
supports broadcasting, we expect the 
transfer of the C-Begin message to be 


efficient. Once the C-Begin message is 
received at each slave node, the moni¬ 
tor switches to the fault-tolerant mode 
of operation, stores the system state in 
the hierarchical permanent memory, and 
checks the possibility of running the 
actions associated with the transaction. 
If an action can run successfully, the 
slave node sends an “okay” message 
(C-Prepare); otherwise, it sends a “fail¬ 
ure” status message (C-Refuse). 

Redundant execution of actions in 
the fault-tolerant mode, use of the dis¬ 
tributed voting algorithm with provi¬ 
sion to recover by itself, and use of two- 
level permanent memory will all 
contribute to improved performance, 
reliability, and fault tolerance. In the 
second phase, if the master node re¬ 
ceives a C-Prepare message from all 
the slave nodes, it commits the transac¬ 
tion by broadcasting the C-Commit mes¬ 
sage; otherwise, it broadcasts the C- 
Rollback message. Also, tasks in this 
phase will complete quickly because the 
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proposed architecture supports the 
broadcast capability and the rollback 
procedure. 

We believe that providing architec¬ 
tural support at the node level and using 
standard protocols will significantly sim¬ 
plify the development of reliable dis¬ 
tributed applications, thereby making 
open distributed systems an attractive 
computing environment. 

Reliability analysis of 
FTODS 

Node reliability. Assume that r rep¬ 
resents the reliability of each processor 
for a given period of time T. This reli¬ 
ability measure should take into account 
the failures caused by hardware as well 
as by software. Detailed Markovian 
methods can be used to predict the com¬ 
bined reliability measure that takes into 
consideration hardware faults and soft¬ 
ware errors — for example, design er¬ 
rors related to system overloads, over¬ 
flow/underflow of queues, etc. Assume 
also that a processor failure is exponen¬ 
tially distributed with a failure rate X. 
Let the number of processors in a node 
be N„ and/denote the number of faulty 
processors at a given time t. Depending 
on the number of faults, the distributed 
voting algorithm uses different proce¬ 
dures, as follows: 

Case 1: Number of faults/< |"iV„/2l. In 
this case, a majority vote is attainable 
and the results obtained by the faulty 
processors can be masked out concur¬ 
rently by the coordinator processor with¬ 
out any extra delay. 

Case 2: Number of faults \NJ2\ </< 
N„ - 1. In this case, the majority of 
processors are faulty. However, there is 
at least one fault-free processor that 
can be identified by the diagnostic rou¬ 
tines. This processor ensures reliable 
execution of the tasks assigned to its 
node, but with a time penalty that re¬ 
sults from invoking the local diagnostic 
procedures. 

Case 3: Number of faults/= N„. In this 
case, all processors of a node are faulty; 
consequently, the node is in a failed 
state. The cluster coordinator invokes 
the distributed node recovery proce¬ 
dure to start a higher level recovery 
procedure, as previously described. 

Node reliability can thus be defined 
as the probability of the node’s being in 


either case 1 or case 2, that is,/< N„- 1. 
The expression for node reliability is 
obtained by computing the probability 
that at least one processor is operating 
successfully and is given by 

R n ( N n ) = C x R bus jr w --'(1 - r)f 

( 1 ) 

where C denotes the coverage of the 
recovery procedure, R bus denotes the 
reliability of the system bus, and 



is the binomial factor and is given by 
N n \ 

In the above expression, the term 
r N n-f denotes the probability of having 
N n -/fault-free processors, while (1 -r)f 
denotes the probability ofhaving/faulty 
processors. The 



denotes the number of combinations in 
which there are /faulty processors cho¬ 
sen from N n in a node. If the coverage 
factor is equal to one, the node can be 
viewed as a parallel redundant system 
with a redundancy level of N„. Node 
reliability can be evaluated as (1 - 

(I-'-)"")- 

Node reliability can be expressed with 
respect to time, if we assume that the 
processors fail according to an expo¬ 
nential distribution function with a fail¬ 
ure rate X. Consequently, node reliabil¬ 
ity at a given time t is given by 

^(A„) = Cx« bus Xj^] 

(exp _x ‘) A '“ -/ (l-exp'^) / 

( 2 ) 

Coverage C is an important parameter, 
and system reliability is extremely sen¬ 
sitive to its value. The coverage factor 
reflects the system’s ability to recover 
automatically from a fault once it oc¬ 
curs during normal operation. It de¬ 


pends on the techniques used to detect, 
mask, locate, and repair faults, and to 
reconfigure and recover from the ef¬ 
fects of a failure. The methods used to 
predict coverage are therefore based on 
assumptions about the expected behav¬ 
ior of faults and how they are handled 
once they occur. Dugan and Trivedi 5 
presented several methods for predict¬ 
ing the coverage factor for different 
types of error behavior assumptions. In 
FTODS, a distributed voting algorithm 
is used to detect faulty processors and 
to mask their errors dynamically. There¬ 
fore, no recovery is needed as long as a 
majority vote can be obtained (case 1). 
Also, this algorithm uses a redundant 
system bus for comparing the results 
obtained by the processors. Since there 
is no single point of failure in the FTODS 
architecture and in the fault-tolerant 
algorithms, the coverage C is expected 
to be high; in this analysis it is assumed 
to be 1. 

A node’s mean time to failure can 
also be evaluated from the above ex¬ 
pression (Equation 2) by integrating 
the node reliability expression: 

mttf =J 

To measure the reliability improvement 
as a result of introducing redundancy, 
we define a measure called the reliabil¬ 
ity improvement factor (RIF). This 
measure describes the relative increase 
in reliability for using N n redundant pro¬ 
cessors to the maximal possible increase 
in reliability. Let’s assume that R„(l) 
denotes the simplex reliability of a node. 
The maximal increase in reliability is 
obtained when R„(l) is increased to 1. 
The RIF for a given redundancy level 
(N n ) is computed as 

mr R„(AJ-/?„(!) 

1-J„(1) 

Figure 9 shows the RIF obtained for 
three different levels of redundancy (3, 
4, and 5). In this analysis, the reliability 
of a simplex bus is assumed to be a 
constant and equal to 0.95, because we 
are interested in studying the effect of 
redundancy level on node reliability. It 
is clear that more than 95 percent of 
the possible reliability improvement can 
be achieved when four processors are 
used. However, a triple modular re¬ 
dundancy configuration (level 3) could 
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if we apply the Syrel algorithm, 6 TR can 
be given as 



TR = + r '^5 

+ r t r 4 r s q, + r iri r 6 q 3 q 5 + r 2 r 3 r 5 q, 
+ r 2 r 3 r 6 q t q s + r 2 r 4 r 5 q t q 3 + r 2 r 4 r 6 q,q 3 q 5 ] 

where <?, denotes the unreliability of 
node i and is equal to (1 - r,). 

A transaction’s reliability can be in¬ 
creased by introducing redundancy so 
that its actions can be executed on sev¬ 
eral processors. Redundant execution 
of actions can be performed on proces¬ 
sors located at remote nodes, all at one 
node, or a combination of these two 
cases. For the network shown in Figure 
10, the transaction reliability is ana¬ 
lyzed for the following three cases: 
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Figure 9. The effect of redundancy level on node reliability. 


be sufficient for situations in which 
the processor’s initial reliability is high. 
The same analysis can be used to mea¬ 
sure the improvement in the MTTF 
when different redundancy levels are 
used. 


tion ai can run on node x, or x 2 , a 2 can 
run on node x 3 orx 4 , and a 3 can run on jc 5 
or x 6 . Because of this redundancy, eight 
possible trees can be used to run this 
transaction: 


Reliability analysis of an atomic trans¬ 
action. Let T denote a transaction with 
a collection of n actions, that is, T = a u 
a 2 ,..., a„, where a i represents an action 
to run on a node. 

The set of nodes that run the actions 
of a given transaction (T) and the set of 
links connecting them form a tree re¬ 
ferred to in CCR protocol as an atomic 
action tree. An AAT is assumed opera¬ 
tional when all its components (nodes 
and links) are operational. 

Figure 10 shows a transaction consist¬ 
ing of three actions a v a 2 , and a 3 in which 
each action can run redundantly on two 
nodes of a cluster. In this example, ac- 


AATj 

aat 2 

aat 3 

AAT 4 
AAT j 


= x b i x b 2 x b 3 x bi x gl x g2 x g3 . 

= x b l x b 2 x b 3 x b 4 x g l x g 2 x gy 
= X b l X b 2 x b 3 x b 4 X g X g 2 X g 3 - 
= X b 1 x b 2 x b 3 x b 4 x g t x g 2 x g 3 - 
~ X b l x b 2 x b 3 x b 4 x g 1 x g 2 x g3 - 


AAT 6~ x b l x b 2 x b 3 x b t * 


AAT^x^x^x.x^; 
AAT 8 = x h x ^ x i, ; x x x g2 x g ^ 


Transaction reliability (TR) can be 
defined as the conditional probability 
that at least one of these trees is opera¬ 
tional. The literature is rich with algo¬ 
rithms to evaluate this probability, and 


Case 1: Execution of redundant ac¬ 
tions at remote nodes. In this case, each 
node has only one processor and the 
actions are executed on remote nodes. 
Concurrency control and redundancy 
management are complicated because 
of the remote distribution of the redun¬ 
dant computations. 

Case 2: Execution of redundant ac¬ 
tions at local nodes. In this case, each 
node has four redundant processors that 
can concurrently execute an action of T. 
Since all of the redundant computa¬ 
tions run on the processors of the same 
node, concurrency control and redun¬ 
dancy management are simplified sig¬ 
nificantly. 

Case 3: Execution of redundant ac¬ 
tions on remote redundant nodes. This 
is a combination of the first two cases. 

Figure 11 shows the transaction reli¬ 
ability for these three cases. Note that 
the transaction reliability for the sec¬ 
ond case is better than that of case 1. 
However, case 2 has twice as many re¬ 
dundant processors as case 1. Further¬ 
more, there is no significant improve¬ 
ment in reliability for case 3 over case 2 
in spite of the fact that case 3 uses twice 
the redundancy of case 2. Moreover, 
the algorithms needed to achieve con¬ 
currency control and redundancy man¬ 
agement in case 3 are more complicated 
than those of case 2 because the redun¬ 
dant actions run on both local and re¬ 
mote nodes. 

From this analysis, we can conclude 
that replicating the computations local¬ 
ly represents a cost-effective solution 
that maximizes reliability and also sim- 
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plifies the algorithms required to achieve 
recovery and consistency control. In 
FTODS, the computing modules are 
designed to provide architectural sup¬ 
port to run transactions in a configura¬ 
tion similar to that described in case 2. 


T he computing modules of the 
proposed FTODS support an 
efficient implementation of 
fault-tolerant algorithms. The use of 
static redundancy within each node guar¬ 
antees fault tolerance and reliable exe¬ 
cution of critical tasks. Furthermore, 
the use of local diagnostic routines to 
identify faulty components reduces the 
complexity of recovery algorithms sig¬ 
nificantly, along with traffic on the com¬ 
munications network, since these func¬ 
tions are executed using the processors 
available at a node. In transaction-pro¬ 
cessing-based distributed systems, per¬ 
manent memory is required for achiev¬ 
ing atomic transactions. In FTODS, the 
permanent memory is designed as a two- 
level hierarchy with semiconductor tech¬ 
nology used in the first level and mag¬ 
netic technology in the second. Providing 
semiconductor permanent memory im¬ 
proves performance significantly be¬ 
cause transactions can be committed 
much faster than by accessing magnetic 
disks. ■ 



Figure 10. An example of a transaction execution. 
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PRODUCT REVIEWS 


Editor: Richard Eckhouse, University of Massachusetts at Boston 
Send review submissions to J.M. Jagadeesh, College of Pharmacy, Ohio State University, Columbus, OH 43210 


One-of-a-kind databases 


Our reviewers — Terry Traub, 
Quentin Fennessy, and Dan Simovici 
— have looked at four popular data¬ 
base systems. Readers should find this 
interesting because the differences 
and similarities in the databases occur 
in such a way that each system falls 
into its own special category. 


FoxPro, Version 2.0 

This version is the latest in a line of 
increasingly powerful relational data¬ 
base packages from Fox Software. 
New features include an improved 
screen painter for automatically creat¬ 
ing user screens, relational query by 
example, an SQL (Structured Query 
Language) interpreter, and generally 
improved processing speed. Although 
it runs on any IBM PC, the program 
functions best on a 386 or 486 in 386 
extended mode. 

When I first used Foxbase (the pre¬ 
decessor to FoxPro) in 1987, it was a 
fast, inexpensive alternative to the 
then-standard dBase III Plus from 
Ashton-Tate. It was a clone of dBase 
III Plus, with a few extra features that 
Ashton-Tate, with its 70 percent mar¬ 
ket share, couldn’t be bothered to pro¬ 
vide. Ashton-Tate, in fact, was so upset 
by the upstart from Ohio that it sued 
Fox Software for copyright infringe¬ 
ment. How times have changed. Fox¬ 
Pro 2.0 is now the most powerful dBase 
clone on the market, and Ashton-Tate 
is gone, bought out by Borland Inter¬ 
national, the makers of Paradox. 

Now that Ashton-Tate is gone and 
dBase IV is being marketed by the 
Paradox people, what future is there 
for the dBase standard? The future 
seems to lie with FoxPro 2.0. This 
product, with an SQL interface that 
supplements traditional dBase com¬ 
mands, finally can be considered 
alongside such multiuser relational 
database systems as Oracle and Sy¬ 
base. FoxPro cannot yet be called a 
replacement for the Sybase SQL Serv¬ 
er because the company has not re¬ 
leased a server version, but it does so 
much now that it is serious competi¬ 
tion for single-user systems or small 


PC networks. In addition, its availabil¬ 
ity for the Macintosh makes it a good 
choice for offices with a mixture of 
PCs and Macs. 

In fact, FoxPro’s SQL interpreter, 
while not so complete as its minicom¬ 
puter cousins, has all the basic fea¬ 
tures and includes the powerful Union 
clause. The SQL commands Create, 
Drop, and Delete are not provided; 
you must still use the dBase equiva¬ 
lents. Nonetheless, for users familiar 
with the SQL language, FoxPro pro¬ 
vides a familiar and easy-to-use envi¬ 
ronment. 

For those who don’t know SQL, the 
relational query-by-example feature 
builds SQL queries interactively by 
letting users press buttons and click 
on names with a mouse. Although 
easy to use, this feature is not always 
intuitive. Fortunately, a chapter in the 
tutorial manual is devoted to building 
queries with this tool and does a good 
job of introducing you to its power. 

The program continues its prede¬ 
cessors’ tradition of putting almost all 
features into pull-down menus and 
pop-up dialogue boxes. In fact, the 
whole system has a Microsoft Win¬ 
dows feel to it, complete with mouse 
interface — except that it’s a charac¬ 
ter-mode program. The program runs 
well in a DOS window in Windows 3.0 
(FoxPro 1.0 did not), but it left me 
wondering when the company will 
come out with a full-blown Windows 
version (it’s promised soon). FoxPro 
is very much a PC product, with its 
roots in the days of the dBase dot 
prompt. Indeed, many menu options 
can be entered in the command win¬ 
dow, which is the standard dBase style 
command-line interface (except that 
you won’t see a dot prompt). If you 
choose a menu option, you see its 
command-line equivalent appear in 
the command window. 

One of the most impressive features 
is the interactive screen builder, which 
lets you set up data-entry screens 
complete with push buttons, check 
boxes, labels, pop-up lists, and text 
fields. The screen builder generates 
the necessary underlying code. You 
can set up fancy screens in just a few 
minutes. The mouse makes it a breeze 


to create and modify the data-entry 
screen; fields and labels are treated as 
movable objects, and you can even 
highlight several of them and move 
them as a group. You can add calculat¬ 
ed fields, push buttons, scroll bars, ra¬ 
dio buttons, labels, lines, and boxes to 
your heart’s content. You can move 
them all around with the mouse and re¬ 
order the fields with one quick com¬ 
mand. The Generate command creates 
a program file that you can compile 
and run to test your work. In just a few 
minutes, with the tutorial book open 
on my desk, I created a complete data- 
entry screen for a database. This is 
quite a timesaver, and I was impressed 
by the readable, commented code that 
was automatically generated. 

The program can call C and assem¬ 
bly-language modules, but you must 
purchase the Library Construction Kit 
($500) to take advantage of this fea¬ 
ture. However, with more than 100 
new or enhanced commands and func¬ 
tions in the basic program, most users 
probably won’t need this feature. 

The improved documentation now 
has more cross-references, but in such 
a large, complex system, you may still 
need some time to familiarize yourself 
with the large command set. In some 
cases, the powerful browser takes care 
of the hard work by letting you scroll 
through rows in a table and examine 
or modify them as you wish. The rela¬ 
tional query-by-example feature and 
the screen painter are also helpful, but 
simply understanding the power avail¬ 
able takes some time. The developers 
have obviously striven to make the 
system as self-explanatory as possible. 
Context-sensitive help is available for 
any feature, and it is no longer neces¬ 
sary to memorize all the @..say..get 
rules for data entry because the sys¬ 
tem generates the screens and the 
code, and cross-references it all. 

Although there are many more fea¬ 
tures than can be discussed in this brief 
review, I’ll mention the more signifi¬ 
cant new goodies. The FoxHelp system 
lets you explore the documentation on 
line, though not in as much detail as 
you might like, and not as hypertext¬ 
like as you might prefer. It also lets you 
set up context-sensitive pop-up help 
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screens for your own applications. The 
FoxDoc system organizes and docu¬ 
ments major programs. The Project 
Manager is Fox’s version of the Make 
utility well known to PC and Unix pro¬ 
grammers. It tracks programs, screen 
files, menu files, reports, and several 
other items and is used to compile a 
program. It compresses indexes to as 
little as one-sixth the size of standard 
Fox IDX files, and they can be pro¬ 
cessed much faster. 

FoxPro 2.0 has emerged as one of 
the top PC databases. Its relatively 
low price ($795), excellent perfor¬ 
mance, large capacity, and easy-to-use 
Windows look and feel are all good 
reasons to go with this program. We 
can only wonder what miracles await 
us in version 3.0. 

Readers can contact Fox Software 
at 134 West South Boundary, Perrys- 
burg, OH 43551; (419) 874-0162; or 
circle Reader Service Number 21. 

— Terry Traub, Fidelity Systems 

ObjectVision 2.0 

The Microsoft Windows program¬ 
ming interface used to be an obstacle 
to casual programmers. People (non¬ 
professional programmers) read about 
the expensive Windows Software De¬ 
velopers Kit and its attendant com¬ 
plexity, and stayed with crusty old 
DOS for their projects. These people 
could handle Turbo Pascal, with its 
simple interface, for applications they 
needed to produce, but they were 
not willing to invest the necessary 
time and money to come up to speed 
with Windows, Microsoft C, and the 
SDK. 

This situation has improved consid¬ 
erably in the last few years. Since Bor¬ 
land announced ObjectVision 1.0 in 
February 1991, the program has gone 
a long way toward making Windows 
application programming accessible. 
Version 2.0 of ObjectVision improves 
on the initial version in many ways. 
Small applications calling for data in¬ 
put, report screens, and a database 
backend are now extremely easy to 
implement, with a short, steep learn¬ 
ing curve. 

The program runs under Windows 
3.0 and lets users create Windows ap¬ 
plications quickly and easily. These 
applications are actually created visu¬ 
ally — there is no need to type in lines 
of code. Forms, logic, and file-access 
capabilities are all available through 
graphical tools. A user can create pro¬ 
fessional-looking applications that in¬ 
terface with such existing databases as 


Paradox, dBase, and Btrieve formats. 
SQL support will be available in 1992. 

ObjectVision has several new fea¬ 
tures that will become more common 
in upcoming Windows applications. 
The Object Bar stays on the screen 
during development and is a source for 
Windows objects like buttons to be 
“dragged and dropped” onto the forms 
without accessing any menus. The Ob¬ 
ject Bar quickly accesses buttons, ta¬ 
bles, text, and logic trees. The Property 
Inspector function is attached to the 
oft-neglected right mouse button. 
Clicking the button displays the prop¬ 
erties of the object (button, graphic, or 
logic) under the cursor to make them 
available for editing. 

ObjectVision also supports OLE 
(Object Linking and Embedding) and 
DDE (Dynamic Data Exchange) for 
communications with other Windows 
applications. The package can use 
DLLs (Dynamic Link Libraries) cre¬ 
ated with other programming lan¬ 
guages or supplied with other Win¬ 
dows applications to extend the set 
of functions. The list of built-in func¬ 
tions looks remarkably like that of a 
modern spreadsheet program, includ¬ 
ing @SUM() and @ATAN(), as well 
as such Windows-specific capabil¬ 
ities as @DDEEXECUTE(), and 
@ADDMENUITEM(). 

Programming in ObjectVision is dif¬ 
ferent from programming in languages 
like Pascal, which is a procedural lan¬ 
guage. If you want to add a large set of 
numbers, you create the logic to do so 
yourself, most likely with a loop. Ob¬ 
jectVision uses a declarative style of 
programming familiar to spreadsheet 
users. In a spreadsheet, you do not 
loop over a range of numbers to add or 
average them. You simply declare that 
one cell in the worksheet is the sum or 
average of that range. In ObjectVision, 
if one value is changed, all values de¬ 
pending on that value are recalculated, 
just as a spreadsheet program would 
recalculate the value of a cell when its 
value depends on changes in other cell 
values. 

ObjectVision is easy to learn and 
comes with a tutorial and many sam¬ 
ple applications to demonstrate how 
to program with it. I put together an 
application that automated expense 
reporting in my company’s format 
with very little trouble. The basic pro¬ 
cedure I used was to design several 
screens, the input form for daily ex¬ 
penses, and the output screen to be 
printed for the accounting depart¬ 
ment. The application streamlined in¬ 
put by offering a list of projects to 
charge from and the user name al¬ 
ready filled in. It also prompted day 


by day for expenses. Personal car 
mileage was calculated at the proper 
rate, and all rows and columns 
summed automatically. Business rules 
such as the maximum chargeable for 
meals could easily be added to the ap¬ 
plication. 

Unlimited runtime licenses are in¬ 
cluded free with the package. (The 
runtime allows any application to be 
run, but not modified.) ObjectVision 
2.0 is $149.95. The upgrade from 1.0 is 
$49.95, or $10 if 1.0 was purchased af¬ 
ter October 1,1991. 

Readers can contact Borland Inter¬ 
national at 1800 Green Hills Rd., PO 
Box 660001, Scotts Valley, CA 95067- 
0001; (408) 438-8400; or circle Reader 
Service Number 22. 

— Quentin Fennessy, ITP Systems 

Progress 

I reviewed the single-user version of 
the Progress 6.2B database manage¬ 
ment system, running on my 486- 
based system. This robust relational 
database system is equipped with a 
powerful development environment 
visible at the single-user level. 

The centerpiece of the system is the 
Progress language, a fourth-genera¬ 
tion vehicle for writing procedures 
that constitute Progress applications. 

It is a vast extension of SQL that par¬ 
tially conforms to the ANSI SQL. 

Progress is structured in terms of 
blocks, which define data-processing 
directives and the environments that 
process the data. It is worth mention¬ 
ing that (for historical reasons) the 
language is a mixture of procedural 
and nonprocedural styles. The first 
programming style originates with pre¬ 
vious versions of Progress; the second 
is due to the incorporation of SQL. 

The result is a powerful, flexible pro¬ 
gramming tool that is a pleasure to use. 

Progress supports character, inte¬ 
ger, and decimal data types. Date and 
various display formats are available 
to the user, as well as validation tests 
and error messages. 

The database system runs within 
640 Kbytes, an attractive feature for 
value-added resellers of PC-based 
software. On the other hand, you can 
also run Progress in protected mode 
in extended memory, which is particu¬ 
larly useful for software developers. 

The Progress editor is a central 
component of the program. It lets you 
write and test Progress procedures, 
and access the data dictionary, where 
all data-definition actions take place. 
The procedure compiler is easy to use, 
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and the error messages are clear. Pro¬ 
cedures may be written in any ASCII 
editor and then compiled in Progress. 

The data dictionary lets you display 
and change data definitions to add 
and delete relations or add indexes to 
them. The dictionary — a fourth-gen¬ 
eration Progress application — is easy 
to use and well documented. When 
defining fields, you can specify not 
only such usual relational database 
parameters as type and size but also 
field titles and column headings — a 
useful feature for developing frames 
based on tables. The dictionary also 
incorporates some powerful and 
unique capabilities, such as changing 
the name of a field globally through¬ 
out all relations or printing table defi¬ 
nitions as special reports. The admin¬ 
istrative function lets you dump and 
load data and data definitions in vari¬ 
ous formats. 

Forms can be designed by using the 
fourth-generation language or the 
Fast Track utility. In the Progress 
language, you write code to generate 
forms, while Fast Track produces 
forms with a visual editor (a prefera¬ 
ble approach). I hope the company 
will find a way to integrate the form 
editor into the package. 

Both Progress and Fast Track can 
generate a variety of reports with a 
number of options for categorizing, 
sorting, and summarizing data. 

Embedded SQL (in the C program¬ 
ming language), Cobol, and Pascal (in 
HLI, or Host Language Interface) are 
available. Moreover, dynamic SQL is 
also supported in HLI, a feature that 
substantially increases the chances 
that further developers will become 
interested in Progress. 

I was initially impressed by the 
CASE component of Fast Track (a 
tool for prototyping database applica¬ 
tions that is also useful to database 
developers in many other ways). This 
menu-driven application generator 
lets you design and test menus, re¬ 
ports, and query-by-form queries, and 
design forms and generate access code 
for them to be used within Progress 
applications. I believe that the frame 
editor, which exists only in Fast 
Track, should be made available in 
Progress itself. 

Fast Track menus are clear and 
their hierarchical structure is intelli¬ 
gently made visible. When an option 
is about to be selected from a menu, 
its descendents are also visible on the 
screen, which lets you think ahead. 
Unfortunately, upon close examina¬ 
tion, many problems arise. For in¬ 
stance, changing the primary index of 
a file is not easy. You have to create a 


new index and make it the primary in¬ 
dex of the file, invalidating the previ¬ 
ous index changes because that file is 
not active. In this regard, I believe 
that Progress designers would greatly 
benefit from more user contact. 

Unfortunately, the manuals (which 
are well presented from a graphical 
standpoint) are sometimes obscure, 
and having so many available options 
can be disconcerting. It is difficult, for 
instance, to create a “fast-track data¬ 
base.” The Fast Track manual indi¬ 
cates that this database can be initial¬ 
ized by copying an empty Fast Track 
database (a somewhat bizarre design 
choice) or by converting a Progress 
database to a Fast Track database. 
Neither worked to my satisfaction: 
The Fast-Track menu does not appear 
even when you successfully complete 
the procedures. What you need to do 
(though not mentioned in the manual) 
is create some relations (called 
“files”) within the database to access 
the main menu. Installation of the 30 
3.5-inch disks also takes over an hour. 

Progress runs on many platforms 
and operating systems (manuals refer 
to Unix, DOS, and VMS, among oth¬ 
ers, which at times is rather cumber¬ 
some). 

Progress is not inexpensive: A sin¬ 
gle-user license on MS-DOS costs 
$1,500, with a $200 runtime license. 
The multiuser version on Unix is 
$4,850, and the runtime license is 
$850. 

Readers can contact Progress Soft¬ 
ware Corp. at 5 Oak Park, Bedford, 
MA 01730; (617) 275-4500; or circle 
Reader Service Number 23. 

— Dan Simovici, University of 
Massachusetts at Boston 

Ocelot — the SQL 

This versatile, SQL-based relational 
database system for microcomputers 
with 808x or 80x86 processors works 
under MS/PC-DOS. Minimal hard¬ 
ware requirements are 320 Kbytes of 
RAM and a floppy disk drive; more 
memory is needed for the version that 
runs under MS Windows 3.0. 

The system supports several lan¬ 
guages for embedded SQL: Microsoft 
QuickBasic Versions 4.0 and 4.5, Mi¬ 
crosoft Basic PDS Versions 7.0 and 
7.1, Microsoft C Versions 5.0 and 
higher, Borland Turbo C Versions 1.5 
and 2.0, Borland C++ Version 2.0, 
Zortech C++ Version 2.1, Borland 
Turbo Pascal Versions 5.0 and higher, 
and Micro Focus Cobol/2. 

Installing Ocelot under Windows is 


easy; instructions are simple and 
clearly written, and the ocelot-like 
icon becomes immediately available. 
The succinctly written manual is very 
readable and to the point. 

Although I tested a single-user sys¬ 
tem, it is worth mentioning that the 
multiuser version offers unusual ver¬ 
satility from the viewpoint of concur¬ 
rency control. The multiuser engine 
offers both time-stamping and lock¬ 
ing, leaving the choice to the database 
designer. 

The system’s import/export facility 
has a fast, simple operation mode. Ex¬ 
porting data from a table is accom¬ 
plished through a nonstandard modifi¬ 
cation of select: 

select ascii file file-name columns 
from tables where conditions; 

On the other hand, importing data 
from a file is achieved through a vari¬ 
ant of insert: 

insert into table-name [list-of- 
columns] [ascii] file file-name; 

The program lets you specify the 
primary key when you create a table, 
and its Alter directive lets you expand 
the table. A particularly attractive 
feature of its SQL dialect is the refer¬ 
ential integrity. However, at this 
point, note that referential integrity is 
not acceptable between otherwise 
compatible types such as CHAR(n) 
and VARCHAR(n). 

Null values are supported. When 
the “not null” option is specified, a 
default value must be provided. Also, 
the presence of null values can be de¬ 
tected by using the condition “is null.” 
The impressive list of supported types 
includes date and time, and functions 
that manipulate these values are in¬ 
cluded. 

Views based on one or more tables 
are supported and, under certain con¬ 
ditions, updates performed on views 
based on one table are acceptable. In 
such cases, views can be defined with 
the “check option,” which means that 
all insertions and updates through the 
view will be checked to ensure that 
they satisfy the view definition. 

Dynamic SQL (which allows SQL 
directives to be generated at execu¬ 
tion time) is also a part of Ocelot. It 
includes the Execute and Describe 
statements and the structure SQLDA, 
whose components provide informa¬ 
tion about the columns of the table 
being retrieved by a dynamic Select to 
the host program. 

Ocelot uses B-tree indexes that may 
involve up to six table columns. Index- 
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es can be clustered; a table can have 
any number of nonclustered indexes 
but only one clustered index. The sys¬ 
tem catalog is accessible from any que¬ 
ry session and is maintained automati¬ 
cally. It includes tables that list keys 
and foreign keys and has an active role 
in enforcing referential integrity. 

A reorganization utility (including 
its source written in Cobol) comes 
with the package. This utility can be 
used for transferring whole or parts of 
databases between Ocelot and other 
SQL-based database systems, backing 
up databases, eliminating unused 
space in the memory area reserved for 
tables, and changing the physical for¬ 
mat of the tables. The source also 
serves as an example of how Ocelot 
works with Cobol. 

You can produce reports by using 


the Reporter utility (the source is 
written in Basic) or the OR.EXE pro¬ 
gram. This utility lets you query the 
database by using SQL or a visual, in¬ 
teractive query-by-example format. 
You can also view and print reports. 
Queries formulated in query-by-ex- 
ample style are translated in SQL 
queries and then executed. Both facil¬ 
ities are easy to use, and users can 
easily customize report layouts. 

The program has some minor prob¬ 
lems. Under Windows 3.0, you should 
use Connect rather than Open to ini¬ 
tiate access to a specific database. Be¬ 
cause cleaning the working window af¬ 
ter an SQL query is not easy, a menu 
option (such as Blank or Clean) would 
be helpful. Also, when you are printing 
a table, the space reserved for different 
columns is not proportional with the 


real width of the fields. On a more gen¬ 
eral level, Ocelot would benefit from 
having stored procedures. Also, Ocelot 
does not yet integrate any screen pack¬ 
age, though the manual hints such an 
action is contemplated. 

Ocelot’s pricing structure is de¬ 
signed to attract software developers 
in the pursuit of a database engine. 
The single-user product (which I re¬ 
viewed) is $195. An unlimited runtime 
license is an extra $500. The fee for 
unlimited distribution of the multiuser 
version is an attractive $1,000. 

Readers can contact Ocelot Com¬ 
puter Services at 10025-106 St., #1502, 
Edmonton, Alberta, Canada T5J 1G7; 
or circle Reader Service Number 24. 

— Dan Simovici, University of 
Massachusetts, Boston 


Random-access digital audio- recording systems 

— Daryl Lowery, Berklee College of Music 


When I first saw a demonstration of 
an early Synclavier Direct-to-Disk 
System from New England Digital, I 
was overcome with lust. Unfortunate¬ 
ly, the price for a four-channel entry- 
level system in 1988 was about 
$65,000 over my budget. Thanks to 
developments in digital signal process¬ 
ing technology — and continued 
drops in memory and storage prices — 
I can now afford the professional- 
grade digital audio recording systems 
described here. 

The three systems I reviewed are 
Digital Audio Labs’ CardD, Turtle 
Beach Systems’ 56K Digital Record¬ 
ing System, and Micro Technology 
Unlimited's MicroSound (see sidebar 
for system information). 

The primary advantage of disk- 
based recording, editing, and mixing is 
that it provides true random access to 
audio samples stored on disk (see 
sidebar on nondestructive editing). 

Each product recommends that 
your hard drive be formatted with at 
least two logical partitions, one used 
exclusively to store soundfiles. As 
soundfiles are stored and deleted 
from the disk, it becomes fragmented. 
A disk-optimizer program must be 
run periodically to compact the files 
into contiguous tracks and cylinders 
to ensure that the hard disk can run 
fast enough for audio recording and 
playback. 

The trio’s features 

This section describes standard 
features and functions common to 


the software components of each sys¬ 
tem. 

Graphic display. All high-quality 
software lets you visually edit your re¬ 
cordings, which is one of the major 
benefits of using these packages. Each 
package reviewed here lets you dis¬ 
play independent waveforms in time 
and amplitude that show the left and 
right channels of a stereo soundfile. 
The Digital Audio Lab (DAL) EdDi- 
tor software display divides into two 
independent upper and lower sound- 
file windows. The file in the upper 
window is opened for read and write, 
while the file in the lower window is 
read only. Samples may be copied 
from the bottom window to the clip¬ 
board and pasted or mixed from the 
clipboard into the top window. 

Zoom commands cause the display 
to center on the current position of 
the cursor so that each sample corre¬ 
sponds to a single pixel, display the 
waveform for the entire soundfile, and 
let the currently selected region of 
samples fill the waveform window. 
When a file is opened, a temporary 
file is automatically created that con¬ 
tains peak waveform amplitudes for 
groups of sound samples. These are 
used instead of the samples in the file 
to speed up the display of a zoomed- 
out waveform. 

The Turtle Beach Systems (TBS) 
SoundStage software provides four 
soundfile windows that let you edit 
your recordings visually. A soundfile 
window contains two views of the re¬ 
cording and several time displays, reso¬ 


lution sliders, and a variety of icons. 
The overview line represents the entire 
soundfile. Dragging the mouse across 
the overview highlights an area of the 
soundfile that is then displayed as a 
graphic waveform. A horizontal slider 
lets you change the time resolution of 
the display, while a vertical slider lets 
you change the amplitude resolution. 

Dragging the mouse over the dis¬ 
play with the right mouse button 
pressed produces a rubber box. When 
the mouse button is released, the area 
enclosed in the box fills the display. 
The Micro Technology Unlimited 
(MTU) MicroEditor software pro¬ 
vides an identical function. In Sound- 
Stage, unlike in EdDitor, redrawing 
the main view takes as long as the 
length of the view; that is, a 10-minute 
display of a recording takes 10 min¬ 
utes to draw. You can set a display pa¬ 
rameter for the maximum view in this 
fashion. This is overridden by the res¬ 
olution sliders. One of SoundStage’s 
best display features is that it main¬ 
tains a stack of the last eight views of 
the soundfile. A previous-view icon 
lets you step back through the stack. 

The MTU MicroEditor software 
provides two views in its Segment/ 
Waveform windows that can be tog¬ 
gled. One view displays the open file 
as a playlist, showing audio segments 
as horizontal bars. The other displays 
a waveform. The samples to be plot¬ 
ted are derived from the recorded 
soundfile and computed by using the 
DSP board. An icon lets you zoom in 
on (or out of) the display in one-grid 
increments. 
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Editing. The DAL EdDitor lets you 
cut, paste, copy, mix, and delete ranges 
of samples from one file to another. 
You actually edit the playlist, which 
tracks all samples deleted from a file or 
added to it from another file. Data for 
the graphic display is drawn from the 
playlist rather than the current file. 
Samples are only written when you 
save a file. 

The EdDitor maintains a list of the 
last 10 editing operations made on the 
top window. Selecting any operation 
on the list causes the top window to 
represent the waveform at the time 
that operation was performed. 

Of the three packages, only Sound- 
Stage provides destructive cut-and- 
paste editing. Destructive Editing re¬ 
quires more time to reshuffle the 
remaining audio on disk. MicroEditor 
provides no way to edit a soundfile di¬ 
rectly. 

Both SoundStage and MicroEditor 
provide scrub play modes to locate 
edit points by ear. The SoundStage 
scrub mode is controlled by the mo¬ 
tion of the mouse relative to its start¬ 
ing position. 

All three programs provide general- 
purpose flags called markers for spe¬ 
cial areas in a file. These are especial¬ 
ly useful during editing. 

Playlist. Each program lets you re¬ 
arrange the play order of sections of a 
soundfile (segment) and save the edit 
decisions as a file (see sidebar on non¬ 
destructive editing again). 

The MicroEditor Mix Screen Seg¬ 
ment Window is like a playlist except 
that you can see when segments will 
play and whether they are overlapped. 
MicroEditor alone can overlap seg¬ 
ments. 

Disk layering. During playback, the 
disk head must move to access one 
soundfile at a time. This happens in 
real time if there are no overlapped 
segments, but it must be computed off 
line and stored in Sound Blocks when 
overlapping exists. Sound Blocks are 
transient groups of samples computed 
when disk layering occurs. They allow 
editing and mixing of overlapped seg¬ 
ments to be done, played, and undone 
at any time. They are stored on disk in 
the Mix File, which uses them for 
playback instead of the actual over¬ 
lapped segments. When Sound Blocks 
are created, they have a specific seg¬ 
ment content based on the segments 
overlapped during the mix. If you 
change or move a segment, the seg¬ 
ment content at that point in the Mix 
File is changed. This causes the corre¬ 
sponding Sound Blocks to be decou- 


System information 

The digital audio recording systems 
discussed in this review require 

• an IBM AT-compatible 286, 386, or 
486 computer with a 12-MHz CPU and 
640 Kbytes of RAM; 

• Hercules, EGA, or VGA graphics 
adapters; 

• MS-DOS 4.01 or higher; 

• a 16-bit RLL, ESDI, or SCSI disk- 
drive controller set up to work with 1:1 
interleaving; 

• a free 16-bit expansion slot; and 

• a large hard-disk drive with a 28- 
ms-or-less random-access time and a 
500-Kbyte/s throughput rate. 

At 44.1-kHz sampling in stereo, 
hard-disk storage requirements are 
10.5 Mbytes per minute. 

I tested each product on both a 25- 
MHz 386 and a 12-MHz 286 with VGA 
and Hercules graphics adapters, DOS 
5.0, an Always IN-2000 SCSI card, 
and a Priam 738 329-Mbyte SCSI 
drive with measured throughput of 
over 900 Kbytes/s and, depending on 
the test, 16- and 18-ms access times. 
Although the products consist of hard¬ 
ware and software components, they 
have sharply contrasting architectures. 
All systems include a 16-bit selectable 
l/O-mapping AT-bus board that pro¬ 
vides the interface to the computer. 

The boards used by 56K and Mi- 
croSound contain a 20-MHz Motorola 
DSP56001 chip capable of 10.5 MIPS. 
The 56K system uses this chip to com¬ 
pute real-time parametric equalization 
and spectral analysis. MicroSound 
uses the chip for performing real-time 


pled; however, they remain on disk. If 
you return the segment to its original 
location, reestablishing the same con¬ 
text, the original sound block is re¬ 
used. Each segment has its own fade- 
in/out durations, and its amplitude can 
be cut or boosted. These changes to a 
segment are computed in real time by 
the DSP board during playback. Mix 
Files can contain over 1,000 nonover- 
lapped or hundreds of overlapped seg¬ 
ments created from up to 20 sound- 
files, with a total length of 2 Gbytes. 

A Mix File can itself be stored as a 
new soundfile, which can then be used 
in other Mix Files. Segments can be 
moved to where they should start 
playing and positioned with the aid of 


fade and gain changes on audio for 
output, digital mixing, and waveform 
display calculations. 

CardD uses the host CPU rather 
than a DSP chip to perform processing 
and contains the 16-bit A/D/A convert¬ 
ers and interface circuitry. 

The 56K and MicroSound boards 
both connect to external interface 
modules. The 56K interface box con¬ 
nects the board with a user-supplied 
external A/D/A converter or DAT re¬ 
corder with digital I/O. No analog I/O is 
provided. The MicroSound I/O module 
is available in several configurations. 

Each system has software that per¬ 
forms digital audio graphic display ed¬ 
iting as well as stereo audio-recording 
and playback. The DAL EdDitor soft¬ 
ware is a graphics DOS-based pro¬ 
gram. TBS SoundStage software runs 
with the supplied Digital Research 
GEM interface. The MTU MicroEditor 
runs under Microsoft Windows 3.0 or 
higher. 

Component prices for the CardD 
system are $795 for the CardD board, 
$250 for the EdDitor, and $295 for the 
I/O CardD. The 56K system retails for 
$1,995. Complete turnkey systems are 
also available. The standard Micro- 
Sound System comes with MicroEditor 
software, a DSP board, and an I/O 
module with unbalanced or balanced 
analog in-and-out for $3,690 and 
$3,890, respectively. The four-channel 
analog option is an additional $1,650 
for unbalanced and $1,850 for bal¬ 
anced. The digital I/O option is $495. 
PC Sound music synthesis software is 
$250. Micro Tools software costs 
$200. Complete 486-based turnkey 
workstations start at $8,200. 


grid lines. They can be crossfaded, ap¬ 
pended, separated, or overlapped. 
Segments must be drawn from sound- 
files with the same sample rate and 
number of channels as the destination 
Mix File. 

Representative tests 

I tested each system for representa¬ 
tive tasks of a digital audio-recording 
editing system. The description of 
each task focuses on the product that 
has the best features in that area. 

CardD: Mastering. The task was to 
reassemble a sequence of songs from 
a recording into a new play order. 
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Direct-to-disk recording and nondestructive editing 

Direct-to-disk recording, also known as tapeless audio production, is a digital 
audio-recording technique similar to that used in making compact discs and digi¬ 
tal audio tapes. Like DAT recording, direct-to-disk recording requires analog-to- 
digital-to-analog conversion, but it uses a computer hard drive rather than mag¬ 
netic tape for storing the resultant audio samples. Both analog and digital 
tape-based recorders operate as linear storage mediums. Because of their supe¬ 
rior access times, hard-disk recording systems provide the random access to au¬ 
dio samples characteristic of CDs at a higher level of performance. 

In nondestructive editing, sections of a direct-to-disk recording can be exten¬ 
sively edited without affecting the audio data within the original recording. Such 
editing also creates an edit/parameter list known as a playlist. The playlist results 
from defining any number of sections, or regions, within the overall recording. 
Once defined, a region can then be inserted into — and accessed from — the 
playlist. Multiple regions can be reproduced in any order. Once a region has 
been placed into a playlist, it is typically assigned a series of edit parameters to 
be performed upon reproduction. 


This involved recording a 20-minute 
portion of four selections from a com¬ 
mercial CD. I booted the EdDitor and 
selected record from the file pull¬ 
down menu. A dialogue box appeared, 
prompting for the file name to be re¬ 
corded. I entered a name, which dis¬ 
played in the Record window. This 
window also displays the sample rate, 
the elapsed time recorded, time re¬ 
maining on the disk, and level meter 
displays. I played the CD and checked 
the record levels. Everything looked 
good, so I pressed Enter to begin re¬ 
cording. My disk-drive light was flash¬ 
ing and the window time displays were 
being updated, so I started the CD. I 
monitored the recording from the out¬ 
put jacks of CardD. I dropped markers 
while recording by pressing the “m” 
key in the silence between selections. 
Around 20 minutes later, I stopped the 
CD playback and the recording. 

A waveform representing the entire 
file was displayed in the bottom read¬ 
only window of the wave editor por¬ 
tion of the program. The markers I 
dropped were labeled A, B, and C. I 
played back some of the soundfile and 
it sounded great. The next step was to 
rearrange the order of the four songs. 

I made sure that the play cursor was 
positioned at the beginning of the file 
and activated the selection mode to 
set an anchor point. As you move the 
cursor, the area between the cursor 
and the anchor point is highlighted to 
indicate the currently selected region. 

I pressed Tab to select the region 
from the beginning of the file to the 
first marker. I copied the currently se¬ 
lected region to the clipboard, select¬ 
ed the read/write window, and pasted 
the contents of the clipboard into it. 


The waveform representing the first 
song was now displayed in the top 
window. 

I used similar methods to copy the 
region between the last marker and 
the end of the file, pasting the selec¬ 
tion in at the beginning of a new file. 
This file now contained the last song 
from the original file followed by the 
first song from the original file. 

A quick listen to the beginning 
playback of the modified file revealed 
a slight click. I easily fixed this by se¬ 
lecting the first few milliseconds of 
the area at the beginning and applying 
a linear fade-in. Next, I checked the 
splice point between the two songs. It 
was transparent! I copied and pasted 
the two remaining songs and ended up 
with a completely reordered master in 
the top window. The entire edit took 
less than 10 minutes. 

I performed the same task with 
Turtle Beach SoundStage and MTU 
MicroEditor with the same success. I 
found SoundStage’s playlist a more 
efficient mechanism for assembling 
and reordering operations. Micro- 
Editor also performed this task easily. 
It is the only program of the three 
that can create blank spaces in be¬ 
tween segments. In general, I pre¬ 
ferred the mouse support offered by 
these two programs. 

56K: Dance remix. This task in¬ 
volved splicing portions of a song and 
reassembling them into a remixed ver¬ 
sion. 

After booting SoundStage, the beta 
version that I tested automatically 
opens one of four soundfile windows. 
A GEM item-selector dialogue box 
lets you open files for recording. You 


can append files, record over them, or 
record at a specified point. Once this 
is done, the recording functions dia¬ 
logue appears. The sample-rate dis¬ 
play shows what sample rate is cur¬ 
rently being received. Recording can 
be triggered on a variety of inputs: 
MIDI/note channel, time code, or 
mouse or keyboard. Play, Record, 

Fast Fwd, and Rewind transport but¬ 
tons work just like those on an analog 
tape recorder, except that they are in¬ 
stantaneous. Meters can be shown to 
display the incoming audio. 

When I clicked on Record, the time 
display began to run. Then I started 
the CD player. When I had recorded 
the first minute or so of the tune, I hit 
the space bar to stop record and then 
played back the file. Now that the 
main soundfile was recorded, it was 
time to define the sections of the tune 
that would become the building 
blocks of my remix. SoundStage calls 
these sections zones. 

When you define a zone by select¬ 
ing an area in the soundfile and click¬ 
ing on the zone icon, SoundStage lets 
you repeat the playback of a selected 
area a specified number of times. This 
is great for seeing how the splice 
works with other things. 

Now that several zones had been de¬ 
fined, it was time to enter the playlist 
editing section of SoundStage. Since 
there are four active soundfiles avail¬ 
able in SoundStage, you can view a list 
of the zones defined in any file by 
clicking on a radio button. Several 
copies of a zone can appear in the same 
playlist. The playlist can be rearranged 
by dragging the events to a new loca¬ 
tion. If you forget what a zone sounds 
like, you can double-click on it to play 
it. In addition to zones, events can be 
chosen from three types of crossfades, 
key press, mouse, MIDI, and SMPTE 
trigger events. (SMPTE is a time-code 
protocol for synchronizing video, film 
and audio equipment). Multiple events 
can be triggered in a playlist. 

I decided to record a few more 
soundfiles for additional material to be 
inserted in the remix. I entered the 
record mode again and recorded a 30- 
second soundfile, which played back 
fine. I exited to the soundfile edit win¬ 
dow as before. This time, the message 
“Error Calculating Plot Error 0020 
677E” was displayed. Okay — I tried 
to record again. Another error was re¬ 
ported: “No digital input found. 

Please check connections.” I quit and 
restarted the program, which greeted 
me with “SoundStage or 56K hard¬ 
ware is not properly installed.” I per¬ 
formed a hard reboot and ran the pro¬ 
gram. When I tried to record, the 
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display indicated “2 buffer over¬ 
flows.” 

SoundStage provides a mechanism 
for precreating an empty file of a 
specified size before recording. The 
manual says this may be helpful if you 
experience recording errors. I tried 
presizing a 1-minute file. The presiz¬ 
ing is done before recording can begin 
but after it is initiated, which can 
cause a significant delay. Nothing spe¬ 
cial occurs to indicate that presizing is 
taking place, so you must watch for 
the counter to start to know when to 
begin recording. 

Although the next recording at¬ 
tempt appeared successful, no sound 
occurred on playback. I exited to the 
edit window, and the waveform for 
the soundfile I had just recorded was 
displayed — but still no sound. I final¬ 
ly ran CHKDSK and discovered that 
the soundfile(s) I had recently record¬ 
ed were cross-linked with sequentially 
numbered .evt files. I didn’t notice 
that they were hidden files. I ran sev¬ 
eral different disk-repair and defrag¬ 
menting utilities. This seemed to help 
for a while, but the same problem 
kept returning. When I called Turtle 
Beach customer support with a list of 
error codes and a detailed description 
of problems, I didn’t get any technical 
explanations. It was suggested that I 
reformat the drive (which I didn’t 
have time to do). 

All things considered, SoundStage 
performed well. I did eventually cre¬ 
ate a pretty slick remix. The days of 
razor-blade editing must really be 


MicroSound: Audio production. 

The MicroEditor tutorial takes you 
through the process of recording and 
assembling a 30-second radio spot (for 
MTU’s MicroSound, of course) from 
audio sources supplied on cassette. 
This inspired me to search for an old 
four-track tape of a radio spot I had 
done in 1984 and update it. 

I first recorded each track of the 
original tape with MicroEditor. When 
MicroEditor runs, the Mix Screen is 
automatically displayed. A dialogue 
box lets you select the sample rate, 
number of channels, and an option to 
precreate the file on disk with param¬ 
eters that specify file length. Sound- 
files with differing sample rates and 
numbers of channels cannot be used 
as sources for the segments in the 
same Mix File. Since I wanted the fi¬ 
nal result to be a stereo mix, I chose 
two channels at the 44.1-Kbyte sample 

I then proceeded to record each of 
the four mono tracks as a stereo 


soundfile. Since I planned to assemble 
these as a Mix File, I expected to 
manually synch them, so I included 
the same click count-off at the begin¬ 
ning of each file. I planned to resize 
each segment so that it would start 
precisely with the first click of the 
count-in. Next, I created a segment 
drawn from the first soundfile that 
contained a drum track with an over¬ 
dubbed bass part and returned it to 
the Mix Screen. I did the same for the 
other three tracks, which contained 
two lead vocals, background vocals, 
several sections of dialogue, and vari¬ 
ous synthesizer parts — all inter¬ 
spersed on each track. When the seg¬ 
ments appeared in the positioning 
window, I positioned each track at the 
beginning of the mix file. The first 
playback caused the entire file to be 
mixed off line because all four tracks 
overlapped. So far so good. 

I decided that I wanted the flexibili¬ 
ty of placing and editing each phrase 
of the lead vocal track individually, so 
I created new segments for each 
phrase. Micro-Tools is a collection of 
optional DSP utilities that include 
time compression or stretching, pitch 
transposition, sample rate conversion, 
filtering, computation of digital wave¬ 
forms, and selected signal and noise 
removal. All of the Micro-Tools pro¬ 
grams — which existed prior to Mi¬ 
croSound — use floating point and 
require a math coprocessor. The 
DSP56001 is not used. I didn’t have 
access to a coprocessor for this re¬ 
view, but I still wanted to test the pro¬ 
grams somehow. My choice was to do 
so on very small files. I wanted to test 
the Micro-Tools denoise DSP utility 
on the very noisy vocals. Therefore, I 
saved each of the six vocal segments 
and five dialogue segments as new 
and very short soundfiles. 

The shortest soundfile was 1.129 
seconds long. I copied it to a work di¬ 
rectory for testing. The first step in us¬ 
ing the denoise utility involves creat¬ 
ing a template of the noise that you 
wish to remove. I created a 0.25-sec¬ 
ond soundfile of the noise immediate¬ 
ly preceding the vocal phrase I wanted 
to process. Then I used a supplied 
utility to convert the two soundfiles. 
to floating point. Next, I ran the de¬ 
noise utility with the fp noise template 
file as a parameter and the fp vocal 
soundfile as input on my 286. The pro¬ 
cessing took 5.5 hours! In all fairness, 
according to MTU, the same task on a 
486 would have taken just a few min¬ 
utes. I used another utility to convert 
the file back to integer format. Still, 
another utility is provided to access 
the MicroSound-AT hardware from 


the MS-DOS command line. I used it 
to play the processed file, with re¬ 
markable results. The noise was com¬ 
pletely removed with no apparent loss 
in fidelity! 

My next task was to replace some of 
the original music tracks. I created a 
new arrangement of drums, bass, and 
three new synthesizer parts with my 
MIDI sequencing program. 

I successfully tested the MIDI trig¬ 
ger using a Roland MPU-401; howev¬ 
er, a SMPTE-capable Music Quest 
card was unavailable for the review. 
Fortunately, the beta version of Mi¬ 
croEditor I tested supports an over¬ 
dubbing mode that can play back one 
file while recording another. I record¬ 
ed 30 seconds of timecode into a 
soundfile and then, using it as the play¬ 
back file, slaved my MIDI sequencing 
program running on a second computer 
to the output. I recorded each se¬ 
quenced part individually in this man¬ 
ner. Once they were positioned as seg¬ 
ments in the Mix Screen, they were 
perfectly in synch. I used the overdub 
feature to record a soundfile that con¬ 
tained “reverb” for the vocal parts by 
using the vocal soundfile for playback, 
sending the output to an external ef¬ 
fects unit, and recording the effects 
return as a new soundfile. This was so 
successful that I used the same trick 
several times, applying different ef¬ 
fects to other segments. 

The last thing I wanted to record 
was a tenor sax solo overdub. To do 
this, I needed to be able to play 
against the music contained in the Mix 
File. Since playback of a Mix File in 
Record Screen is not supported, I 
saved the project Mix File as a sound- 
file and used it for the playback file. 

The final result was a Mix File con¬ 
taining 40 segments drawn from 24 
soundfiles (four over the documented 
limit). I would probably have used 
more than 50 tracks in a professional 
multitrack studio to achieve similar 
results. After positioning and adjust¬ 
ing the levels of all segments, I ended 
up with the best quality recording I’ve 
been on. 

In fact, all three systems produce 
exceptional better-than-CD quality 
audio at very competitive price-per- 
performance ratios. 

Readers can contact Digital Audio 
Labs at 6311 Wayzata Blvd., Ste. 330, 
St. Louis Park, MN 55416; (612) 559- 
6104; Turtle Beach Systems at PO 
Box 5074, York, PA 17405; (717) 843- 
6916; and Micro Technology Unlimit¬ 
ed at Wind Chime Court, PO Box 
21061, Raleigh, NC 27619; (919) 870- 
0344; or circle Reader Service Num¬ 
bers 25, 26, or 27. 
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NEW PRODUCTS 


Contact or send releases to Christine Miller, Computer, 10662 Los Vaqueros Circle, PO Box 3014, Los Alamitos, CA 90720-1264; Internet, s.c. miller @ compmail.com. 


Voice-processing applications 

Graphical tool for developing voice applications 


Digital Equipment Corp. has an¬ 
nounced DECvoiceBuilder Version 
1.0, a tool with a graphical user inter¬ 
face that lets users develop or change 
a voice application without writing 
code. Nonprogrammers can create 
voice-response applications by select¬ 
ing icons for voice-processing func¬ 
tions (such as answering the phone) 


and connecting the icons into a net¬ 
work that represents the application. 
When this network is saved, DEC¬ 
voiceBuilder automatically generates 
C source code for the application. 

DECvoiceBuilder consists of an 
application production environment 
(including an applications editor and a 
recording system) and a runtime envi- 


Voice input for DOS and Windows 


The Phonetic Engine 400 (PE400) 
from Sound Systems Inc. is a speech- 
recognition system for developing 
speech-based DOS and Windows ap¬ 
plications. 

The PE400 is based on a propri¬ 
etary dual-processor ISA-compatible 
circuit board that plugs into PC AT, 
386, and 486 computers. A minimum 
system consists of the PE400 circuit 
board and PE400/RTS speech-recog¬ 
nition runtime software. This system 


converts speaker-independent contin¬ 
uous speech input into text input and 
comes with a 40,000-word vocabulary 
that users can augment. The single¬ 
unit price for the PE400 board is 
$2,875; for the RTS software, $995. 

Sound Systems also offers the 
DS400 Developer’s System. In addi¬ 
tion to the PE400 board and RTS soft¬ 
ware, the DS400 system includes 
VoiceMatch — an integrated develop¬ 
ment toolkit for speech applications. 


Automating the link between telephones and computers 


Vysion announced Vector/LS, an 
interactive voice-response system that 
includes many of the technologies in 
the company’s Vector system. The 
Vector/LS, like its predecessor, is de¬ 
signed primarily for automating infor¬ 
mation exchange between Touch 
Tone telephones and computer data¬ 
bases. 

The Vector/LS hardware is more 
compact (7 x 13 x 15.75 inches), and 
the system is targeted for smaller, less- 
complex voice-processing operating 
environments. It supports two or four 
telephone lines in two-port increments 


and stores up to two hours of digitized 
speech on disk. It can operate in a 
stand-alone mode or communicate 
with a host application processor. 

VPM Vector/LS software consists 
of a voice-processing module that sup¬ 
ports a loop-start (analog) telephony 
interface, caller message recording via 
telephone lines, on-site changes of 
system options and parameters, and 
built-in diagnostics. 

Optional features include a user- 
definable menuing system, a vocabu¬ 
lary development interface, and a 
voice-programming language. 


Interactive modular architecture 


AT&S has introduced VoiceMagic, 
an interactive voice-response software 
platform for voice-processing applica¬ 
tions. VoiceMagic includes standard 
auto-attendant functions such as call 
queuing, queue position announce¬ 
ment, and secondary call transfer. 
Standard voicemail functions include 
nine personal greetings, call screen¬ 
ing, nine private and 99 public distri¬ 
bution lists, message forwarding and 


broadcast, and return receipts. 

VoiceMagic has a modular archi¬ 
tecture that uses action ID types to 
drive all functionality. This structure 
lets users add functions such as un¬ 
limited hierarchical audiotext trees. 
The setup system uses pop-up screens 
for each action ID type. 

The standard software is $2,295. 
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ronment. The tool supports the Multi- 
line DECvoice functionality in a VAX 
4000 or a Micro VAX 3000 environ¬ 
ment. This functionality includes 
voice digitization, text-to-speech syn¬ 
thesis, and voice recognition. 

Prices start at $10,000. 

Reader Service Number 36 


VoiceMatch is delivered in two func¬ 
tionally identical configurations for 
DOS and Windows that let users at¬ 
tach speech input to existing applica¬ 
tions. Developers can use the 
VoiceLib C-language runtime library 
to create speech-based applications 
from scratch. 

The single-unit price for a complete 
DS400 development system is $4,995. 

Reader Service Number 37 


Suggested retail price for a basic 
four-line Vector/LS system is $15,000. 

Reader Service Number 38 
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More developments in parallel processing 


64 nodes in a PC chassis 

Alta Technology has announced the 
PS series of scalable parallel super¬ 
computers. The systems use the SGS- 
Thomson T9000 chip and feature flex¬ 
ible backplane interconnections based 
on high-performance packet-routing 
technology. They scale from the 1- 
Gflops desktop with 64 processing 
nodes up to a 64-Gflops 4,096-node 
system. Memory options range from 32 
Mbytes to 512 Gbytes, with single- and 


double-bit error detection/correction. 

The PS systems will be implement¬ 
ed as compute servers for Sun, IBM, 
and Hewlett-Packard workstations. 
Operating systems that support paral¬ 
lel versions of C, C++, and Fortran 
conform to Unix and X.ll standards. 

The series also supports UltraNet, 
Hippi, and SCSI network and periph¬ 
eral interface standards, providing 
high bandwidth to external devices 


through parallel communication links 
running at 50 Mbytes/s. The initial pe¬ 
ripheral I/O bandwidth is scalable to 
2.5 Gbytes/s. 

The company has accepted orders 
for prototype deliveries under nondis¬ 
closure agreements and plans produc¬ 
tion shipments by the end of 1992. 
Contact the company for pricing. 
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Entry-level system comes with parallel software 


Parsytec has announced the GC el 
system for computational fluid dy¬ 
namics or matrix operations. The sys¬ 
tem uses T805 transputers with the 
same architectures that will be used 
with T9000 machines. GC el emulates 
packet-switching network routers in 
the Parix software environment devel¬ 
oped to scale with 64 to 16,384 proces¬ 
sors. Computational power ranges 
from 1 to 400 Gflops. Each Gflops of 
performance is matched by an inter¬ 


processor band of 1 Gword/s or 4 
Gbytes/s. 

The software architecture — not an 
operating system — lets a small kernel 
on each processor handle runtine 
functions. Part of the environment 
runs on front-end Unix workstations 
and part on the GC machine. Tools 
and software can be divided into those 
for program development and execu¬ 
tion and those for machine adminis¬ 
tration and control. Program develop¬ 


ment is performed on the host com¬ 
puter by using standard Unix tools. 
Optimizing cross-compilers compile 
programs, which are linked with the 
kernel. C and Fortran compilers are 
available, as is the Inmos toolset Oc¬ 
cam compiler. 

The GC el-2/128, including soft¬ 
ware, starts at $400,000 (allow six 
weeks for delivery). 
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DEC adds to 12000 series 

Digital Equipment Corp. has an¬ 
nounced DECmpp 12000-LC models 
with 1,024, 2,048, or 4,096 processors, 
each with two different main-memory 
increments. Overall main memory 
ranges from 16 Mbytes to 256 Mbytes. 

The systems come in a low-profile 
cabinet with up to 300-Mflops perfor¬ 


mance. A DECstation 5000 worksta¬ 
tion front end based on the Ultrix op¬ 
erating system, integrated software- 
development tools, and a one-year 
service warranty are included. 

The company has also announced 
collaboration with Intel Corp. on a va¬ 
riety of joint software projects for 


massively parallel computers. They 
plan to announce an architecture-in¬ 
dependent high-level programming 
language compiler by the end of 1992. 

Prices for the 12000-LC models 
range from $124,800 to $390,200. 
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Fuzzy logic development 


Use an expert editor 

Fuzzy Systems Engineering has re¬ 
leased the Manifold Editor for design¬ 
ing fuzzy systems by capturing the ex¬ 
pert judgments needed to build them. 

The Manifold Editor interface dis¬ 
plays a two-dimensional matrix of 
fuzzy system rules for viewing and ed¬ 
iting rules. The textual gradient of the 
outputs aids visualization of the esti¬ 
mation surface shape. Users can view 
the geometric adjacency of rules with 
up to five independent antecedents by 
observing a two-dimensional slice 


through the hyper rectangle of the in¬ 
put data space. 

The editor allows up to five input 
dimensions and two output dimen¬ 
sions in the estimation surface design. 
Each dimension can be described by 
up to 11 fuzzy sets. Up to 161,051 
rules can be defined and edited for 
each fuzzy estimation surface. Output 
selection in each rule is initiated by 
using a mouse. 

Users can conduct piecewise editing 
of fuzzy sets. Tools include simple 


graphical editing of triangular and 
trapezoidal sets, detailed graphical ed¬ 
iting of arbitrary sets, and translation 
from simple piecewise sets to arbi¬ 
trary free-form ones. 

The editor outputs expert informa¬ 
tion as an “include” file for use in ap¬ 
plication code. Languages include C, 
Basic, and Fortran. 

The Manifold Walker testing tool 
allows static testing of the estimation 
surface at any time during the design 
cycle. 
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The Manifold Editor includes an 
example executable fuzzy system with 
source code and requires a 286, a 
mouse, a VGA monitor, and MS Win¬ 
dows 3.0 in standard or enhanced 
mode. It costs $250 plus $20 for ship¬ 
ping and handling. 
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Fuzzy logic on the AT bus 

The CubiCard hardware controller 
for fuzzy logic engineering applica¬ 
tions combines an AT-bus-compatible 
circuit board with an enhanced ver¬ 
sion of HyperLogic’s CubiCalc RTC. 
The native system is an MS Windows 
application that uses the board direct¬ 
ly as a real-world interface. It can also 
generate stand-alone C code for DOS 
or Windows applications based on 
embedded microcontrollers. 

Sixteen single-ended (or eight dif¬ 
ferential) analog input channels and 
two analog output channels are pro¬ 
vided with 8-bit resolution. Eight bi¬ 
nary inputs, eight binary outputs, and 
three fully programmable, cascadable 
times are available. Multiple boards 
can be used in a single system to in¬ 
crease the number of channels. 

CubiCard RTC Fuzzy Logic Shell 
software provides the platform for de¬ 
signing the fuzzy control system. The 
software includes all features of Cubi¬ 
Calc, with special procedures added to 
configure board hardware and inte¬ 
grate it into the program excecution 
cycle. Runtime hardware-support li¬ 
braries and diagnostic software com¬ 
plete the system, which sells for 
$1,495. 
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Learning tool 

The ADS230 training/development 
kit from American NeuraLogix fea¬ 
tures a PC-compatible snap-in board 
equipped with an NLX230 fuzzy mi¬ 
crocontroller. The kit also contains 
controlling software and documenta¬ 
tion for experimenting with the tech¬ 
nology. 

The NLX230 can also sustain devel¬ 
opment efforts for AI applications. 
The company claims the single-chip 
processor, which comes in a 40-pin 
DIP, is 30 to 40 times faster than typi¬ 
cal software-based or software/hard¬ 
ware hybrid solutions. 

The ADS230 kit costs $395. 
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National University of 
Singapore 

Department of Electrical Engineering 


Appointments 

The Department of Electrical Engineering invites applications for teaching and 
research appointments from candidates with a PhD degree in one of the following 


Computer Communications 
Optical Fibre Communications 
Computer Architecture and Systems 

Besides appointments on normal 3-year contracts, visiting appointments for one 
to two years may be considered. 

Gross annual emoluments range as follows: 

Lecturer/Research Scientist S$53,160 - 64,200 

Senior Lecturer S$58,680-100,310 

Associate Professor S$88,650 -122,870 

(US$1.00 = S$l.64 approximately) 

The commencing salary will depend on the candidate's qualifications, experience 
and the level of appointment offered. 

Leave and medical benefits will be provided. Depending on the type of contract 
offered, other benefits may include: provident fund benefits or an end-of-contract 
gratuity, a settling-in allowance of S$1,000 or S$2,000, subsidised housing at nominal 
rentals ranging from S$100 to S$216 p.m., education allowance for up to three children 
subject to a maximum of S$16,425 per annum per child, passage assistance and bag¬ 
gage allowance for the transportation of personal effects to Singapore. Staff members 
may undertake consultation work, subject to the approval of the University, and re¬ 
tain consultation fees up to a maximum of 60% of their gross annual emoluments in a 
calendar year. 

Lee Kuan Yew Postdoctoral Fellowship 

Applicants for appointment as Research Scientist may also apply for the Lee Kuan 
Yew Postdoctoral Fellowship, which will be awarded to candidates with excellent 
academic records and research potential and who had obtained their PhD degrees in 
the last few years. A stipend will be provided under the Fellowship which will be 
held concurrently with the candidate's appointment as a Research Scientist. 

Facilities 

The Electrical Engineering Department has currently an academic staff strength of 
68 with 21 laboratories, all of which have excellent facilities for teaching and research. 
In addition, there are two externally funded research centres: Centre for Optoelec¬ 
tronics and Centre for IC Failure Analysis and Reliability. Facilities include a Riber 
32P Molecular Beam Epitaxy System and 2 liquid phase epitaxy systems for research 
into III—V compound devices. A wide range of computing resources are available, 
including numerous PCs, SUN Sparcstations, Microvaxes, and HP 9000 Series 300s. 
The University Computer Centre operates an 1BM3081 KX2, and has acquired a high¬ 
speed campus-wide network directly linking the staff's PCs (now provided to every 
staff member) to the various computing resources, including 2 supercomputers based 
in the nearby Science Park. A number of large-scale research projects are in progress, 
including an optical LAN joint effort with Singapore Telecoms and a project to de¬ 
velop VLSI design tools jointly with Chartered Semiconductors. The Department has 
spearheaded the formation of the national Institute of Microelectronics and has re¬ 
cently been commissioned to establish a national Magnetics Technology Centre. 

Application forms and further information on terms and conditions of service may 
be obtained from: 


The Director 
Personnel Department 
National University of Singapore 
10 Kent Ridge Crescent 
Singapore 0511 


The Director 

North America Office 

National University of Singapore 

55 East 59th Street 

New York, NY 10022 USA 

Tel: (212) 751-0331 


Enquiries may also be sent through BITNET to: PERLCH@NUS3090, or through 


Telefax: (65) 7783948. 


June 1992 






SYSTEMS NEIWORK ARCHITECTURE (SNA) NEIWORKS 

edited by Edwin R. Coover 


Optical storage 
over the platforms 


The papers in Systems Network Architecture Networks examine the: 

* Principal components of an SNA network and their functions 

* Development of SNA and its current capabilities 

5k Extent of the networking options offered for office environments 

fit Technologies employed in managing SNA networks 

5k Role that SNA will play in providing future computer-based services 

This tutorial introduces the reader to the design, operation, and manage¬ 
ment of IBM’s Systems Network Architecture. Each chapter begins with an 
overview of the principal issues, a discussion of the terminology, and a 
summary of each paper included in that chapter. 

Sections: Introduction, The Beginnings: The Early “Star" Network and SNA 
Terms, Extending the Network, SNA Operations and Maintenance, SNA and 
the Office, SNA Network Management, The Future of SNA, Glossary, Anno¬ 
tated Bibliography, About the Author. 

C.400 PAGES. JULY 1992. HARDCOVER. ISBN 0-8186-9131-X. 

CATALOG #2131 — * $70.00 MEMBERS $40.00 
(* prepublication price) 



2nd INTERNATIONAL CONFERENCE ON 
SYSTEMS INTEGRATION -ICSI '92 


Choose WORM or erase 

Introl Corp. has announced 600- 
and 1,000-Mbyte multifunctional opti¬ 
cal subsystems for Sun workstations. 
The single-unit systems can operate 
with write-once, read-many drives or 
erasable drives. Users can store data 
in a permanent or rewritable manner. 

The company’s SCSI-Flex software 
package includes a custom device 
driver, an automatic installation utili¬ 
ty, Unix command-line utilities, and a 
Windows-based optical management 
application. 

The subsystem starts at $5,095. 

Reader Service Number 45 


Fast data transfer on a 
rewritable disk 

Nikon has announced the Magneto- 
Optical Disk Drive System, which fea¬ 
tures a 2,200-Kbyte/s data-transfer 
rate on a rewritable disk, a 1,500 rpm 
rotation speed, and a SCSI interface. 
The disk controller read data-transfer 
rate is 1.43 Mbytes/s. 

Approximately 4 Gbytes of code or 
image data can be recorded on the 12- 
inch double-layered disks. 

Reader Service Number 46 


HP multifunctional library 


This volume focuses on the integration of technologies, processes, and 
systems, and on the development of mechanisms and tools that provide 
solutions to complex multidisciplinary problems. ICSI '92 contains 78 
papers emphasizing the management of large-scale integration and 
dealing with recent research in theory, design, implementation, utiliza¬ 
tion, and experiences of integrated processes and systems. 

Sections: Managing System Integration, Software Prototyping Require¬ 
ments Engineering, Application, Software Process Model, Large-Scale 
Systems Integration in Japan, Software Environments, Open Systems, 
Real-Time Systems, Networking Issues, Tools and Technologies, Soft¬ 
ware Development Model, Databases, System Specifications. 

768 PAGES. JUNE 1992. HARDCOVER. ISBN 0-8186-2697-6. 

CATALOG #2697 —$120.00 MEMBERS $60.00 


Call Toll-free 1-800-CS-BOOKS 
or FAX (714) 821-4010 

in California call (714) 821-8380 


^ IEEE COMPUTER SOCIETY 




Hewlett-Packard has announced the 
Model 10LC 5.25-inch multifunctional 
optical-disk library consisting of 16 
disks with a total 10.4-Gbyte storage 
capacity. The library supports image- 
management, archival and hierarchi¬ 
cal storage, and unattended backup 
for PC and workstation networks. 

Model 10CL exhibits rates of 40,000 
hours mean time between failures and 
300,000 average disk exchanges be¬ 
tween failures. It features a disk-drive 
mechanism with a 1-Mbyte/s transfer 
rate and a 27-ms average seek time. 
The average disk-exchange time is 
about 8 seconds. 

Model 10LC uses a rotating mail- 
slot design to help load disks. The re¬ 
writable format used in the drive con¬ 
forms to the Continuous Composite 
ISO/IEC Standard 10089, Format A, 
and the write-once format conforms 
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to CCW standards ECMA 153 and 
ISO DIS 11560, according to the com¬ 
pany. 

The library costs under $10,000 (in¬ 
cluding one drive). Users can order 16 
HP rewritable or write-once optical 
disks for an additional $2,960. 

Reader Service Number 47 


Go for the max 

The Opti/max SCSI rewritable opti¬ 
cal disk subsystem for Sun worksta¬ 
tions features a 7.6-ms average access 
time, according to its manufacturer, 
Unison Information Systems. The 
bootable subsystem consists of one 
5.25-inch rewritable optical disk, a 
proprietary SCSI-to-SCSI caching 
controller, the enclosure, and an unin¬ 
terruptible power supply. It uses the 
standard Sun driver to preserve com¬ 
patibility factors. 

Reader Service Number 48 


Removable cartridges for 
the VAX 

Emulex Corp. has announced the 
Palomar series of rewritable optical 
storage systems, which provide from 
15 to 85 Gbytes of storage in remov¬ 
able 600-Mbyte cartridges. The sys¬ 
tems are designed for SCSI interface, 
Qbus, Unibus, and HSC-based VAX 
systems or clusters and include a host 
adapter, optical jukebox, and juke¬ 
box-management software. Optical 
applications software is also available 
for backup/random-access restore and 
for hierarchical storage management. 

Palomar offers the use of file sys¬ 
tem standards and native VMS device 
drivers, which lets users interchange 
disks between Palomar systems con¬ 
nected to different VAX computers 
and DEC’S WZ104 rewritable optical 
drive. Each standard SCSI interface 
jukebox ports across different CPUs 
when the SCSI host adapter is re¬ 
placed. 

LaserManager software handles file 
and volume management through op¬ 
erator utilities, catalog functions, and 
a file-and-volume information data¬ 
base. 

Prices range from $57,385 for 15 
Gbytes of storage to $205,800 for 85 
Gbytes. 


Reader Service Number 49 



The Opti/max optical disk subsystem measures 16 x 11.5 x 10.75 inches and 
holds an additional 600 Mbytes with each optical cartridge. 


Disk library for mainframes 

The Kodak Optistar Storage System 
(KOSS) for IBM mainframes consists 
of a 1-Tbyte 6800 automated WORM 
library, the Data/Ware DW34850 con¬ 
troller, and item-access application 
software. 

One 14-inch optical disk from the 
system 6800 stores 10.2 Gbytes of 
data, which is equivalent to the capac¬ 
ity of 50 3480 tape cartridges. The 
6800 comes in multiple configurations, 
ranging from a single-drive stand¬ 
alone to a two-drive library with 100 
disks that applications using multiple 
automated disk libraries can use to 


provide over 4 Tbytes of data capacity. 

The system’s robotic control has a 
dual-picking mechanism that retrieves 
one disk while another is being re¬ 
placed. 

The interface between the optical 
storage system and the mainframe 
emulates the IBM 3480 magnetic tape 
subsystem to allow KOSS attachment 
as a virtual plug-and-play device with¬ 
out changing host operating-system 
software. 

KOSS costs $400,000. 

Reader Service Number 50 



A KOSS with 100 10.2-Gbyte disks per library results in a footprint of 27 
square feet per Tbyte. 
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1C Announcements _ 

Company, Model, Function_ Comments r.S. No. 


AMI Software package from American Microsystems Inc. runs on Sun 4 workstations and con- 

Netrans FPG A-ASIC verts FPG A netlists from either Actel, Xilinx, or Altera into ASIC netlists. Package includes 

Conversion software Netrans translation software, ASIC design optimization tools, and ASIC design kit compo¬ 

nents. Price: $15,000 (tailored to one FPGA supplier); $5,000 (upgrade for another supplier). 

Crystal Semiconductor Developed jointly with Sun for Sparc-based multimedia workstations, this monolithic 
CS4215 CMOS device integrates a stereo 16-bit A/D converter and a stereo D/A converter using del- 

Stereo codec ta-sigma conversion techniques. Sample rates range from 8 to 48 kHz; SNR greater than 80 

dB. Packaged in 44-lead PLCC. Price (in 1,000s): from $30. 


Cyrix 

Cx486SLC-25 

Microprocessor 


Fujitsu 

MBM10xC524-15, 

MBM10xC520-15 

ECLSRAM 

Fusion Data Systems 

TokaMacELC 

Accelerator 


This 25-MHz CPU executes 486SX instruction set on DOS, Windows, and Unix, and is com¬ 
patible with the 386SX bus and pinout (100-pin QFP). Includes a single-cycle execution unit, 
32-bit internal and 16-bit external data paths, and on-chip 1-Kbyte cache. Power supply is 
+5V. Draws less than 0.5 mA while input clock is in suspend mode. Price (in 1,000s): $119. 

Family of six emitter-coupled logic SRAMs use BiCMOS and 0.5-pm design-rule processes. 
C524 devices are configured 1 Mword x 4 bits, reconfigurable to 2 x2. C520 devices are 4 
M words x 1 bit. Access time is 15 ns. Available in standard plastic 32-pin and 36-pin TSOPs or 
SOJ packages. Price (in 1,000s): $425. 

By using the 25-MHz 68EC040 processor, which lacks the math coprocessor and memory 
management unit built into the standard 68040, the TokaMac ELC lowers the cost of acceler¬ 
ating performance for Macintosh LC desktop publishing, graphic design, and other compute- 
bound applications. Price: $1,295. 


Hitachi America Mixed-signal processor for 1.8-inch hard disk drives provides all data channel functions, in- 

HD153030F eluding a programmable active filter, on one chip. Manufactured in 1.3-mm BiCMOS pro- 

Data channel processor cess, the HD153030F transfers data at 50 Mbps. It requires 780 mW from a 5 V supply. Sleep¬ 
mode dissipation is less than 10 mW. Samples available. Price (in 1,000s): $18. 

Hitachi America The company has redrawn its HG51A series CBICs for 0.8-pm CMOS to increase operating 

HG51B series speeds up to 2.5 times, reduce power consumption by 50%, and reduce design dimension by 

Cell-based ICs 33%. Comprehensive design tools include specialized cell libraries, one for high-perfor¬ 

mance and one for high-density cells, and a design and test environment based on a tool suite 
from Compass Design Automation. 


Intel 

486DX2 

Microprocessor 


Rohm 

MCH18 

Capacitors 


Speed-doubler technology lets the internal frequency of this processor operate at double 
that of the rest of the system. Accordingly, the CPU, FPU, and cache execute at 50 MHz using 
the same 25-MHz bus of the earlier 486DX systems. This supports performance enhance¬ 
ments without requiring a new generation of supporting components. Price (in 1,000s): $550. 

Available in 0603 package, these ceramic-chip capacitors measur^ 1.6x0.8x0.9 mm. Capaci¬ 
tances range from 0.5 pF to 560 pF for NPO dieletrics and 200 pF to 6,800 pF for X7R dielec¬ 
trics. Designed for both wave and IR reflow soldering. Available in 8-mm tape on 7- or 13- 
inchreels (4,000- and 16,000-piece,respectively). Price (in4K reel): from 2.5 cents. 


Siemens 

80C51(5H/7H)-3J, 
83C51(5AH/7AH)-5J 
EEPROM macrochips 


Four configurations of multichip modules that fit into the IC footprint, software compatible 
with industry-standard 8051 architecture, offer on-board EEPROM functionality. Two con¬ 
figurations feature extended on-chip RAM (XRAM). Other general features: 8-bit or 10- 
bit A/D converters with up to 12 multiplexed inputs; up to 18-MHz processing speed; and up 
to eight data points. Price: from $345. 


Texas Instruments 
4-Mbit VRAM 


Toshiba 
TC180G 
Gate array 


Video RAM integrates a 256-Kword x 16-bit DRAM array and a 256-word x 16-bit serial ac¬ 
cess memory. Features include split register transfer read, write per bit, and CAS-before- 
RAS refresh. Offered in JEDEC-standard 64-pin SSOPs at two speed variations. Samples 
scheduled for third quarter availability. Price: $70. 

Series of gate arrays use 0.5-micron CMOS process and achieve a gate delay time of 0.21 ns at 
3.3 V. The new series comprises 12 master array sizes with gate complexities ranging from 
20,000 to 800,000 raw gates. Cell library is functionally compatible with TC160G/TC163G se¬ 
ries. Orders will be accepted from Sept. 1992. 
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Microsystem Announcements 

Company, Model, Function Comments R.S. No. 


Acculogic Half-card memory expansion board gives up to 16 Mbytes of extended or LIM (Lotus-Intel- 

RAMpAT!-Plus Microsoft) 4.0 expanded memory for PC AT bus-compatible systems, including many lap- 

Memory board tops. It comes with a self-installing diskette. Has four sockets that can accommodate either 

1M x 9 or 4M x 9 SIMMs. Price: $249. 


Burr-Brown 
ADC750 
A/D converter 

CHI Systems 
6U Hippi-VME 
Interface board 


Data Translation 
DT3801 series 
Data acquisition board 


Dover Electronics 
ESP 8680 

XT miniature computer 


Markenrich 
MAD 100 

Data acquisition card 


Micro 2000 
Post-Probe 
PC diagnostic card 


Odetics 

TPro-BI 

VAX time-code reader/ 
generator 


Proxim 

RangeLAN/LT 
Adapter card 


Sabtech Industries 
NATO Hawke 
Interface board 

Tech-Source 
GXTRA/1 
Graphics accelerator 


Vigra 

VS-30 

Audio processor board 


This 400-kHz conversion subsystem has 22-bit floating-point resolution on 3x 5-inch card. 
Includes 16-bit sampling A/D converter, automatic gain ranging amplifier, and eight-channel 
input multiplexer. Dynamic range isll6dB. Power dissipation is 5.3W. Price (in 25s): $1,540. 

Source and destination Hippi channels support 25-Mbyte/sec block transfer rates for VME 
32 and 55-Mbyte/sec rates for VME 64. Includes Sun- and Silicon Graphics-compatible driv¬ 
ers, 32-bit-wide 100-Mbyte/sec auxiliary port bus, 25-MHz microprocessor, and DMA con¬ 
troller that allows FIFO to FIFO as well as FIFO to 2-Mbyte SRAM buffer. 

PC AT-compatible board supports real-time, synchronous, mixed-signal measurement and 
processing. Uses TMS320C40 DSP’s six on-board communications ports and six-channel 
DMA engine to service analog and digital I/O subsystems, leaving the CPU free for signal 
processing. Available in Aug. 1992. Price: $7,595. 

This “Extremely Small Package” module, based on Chips and Technologies’ 8680 single¬ 
chip computer, measures 1.7 x 5.2 inches. Includes integrated nonvolatile memory card 
socket, CGA graphics, up to 1 Mbyte DRAM, keyboard interface, one serial port, and con¬ 
nectors for expansion. Comes with development kits. Price: $995. 

Gives IBM PCs and compatibles simultaneous sampling of up to four channels. In single¬ 
channel mode, the maximum sample rate is 100 MHz; in dual- and quad-channel modes, it is 
50 and 25 MHz, respectively. Programmable sample rates range from 2.5 kHz to 100 MHz; 
programmable input gain, from 640 mV to 64V full scale. Price: $2,995. 

Universal post card diagnoses all IBM-compatible PCs, including those that won’t boot. Dis¬ 
plays all diagnostic signals at the same time. Monitors hi-low clock and oscillating cycles to 
distinguish between clock chip and crystal failure. Includes tri-state logic probe, four-posi¬ 
tion DIP switch, and Micro-Scope diagnostic software. Price: $399. 

Single board generates IRIG-B and reads all major industry-standard time codes generated 
by other devices. Optional GPS receiver module receives universal coordinated time and po¬ 
sition information transmitted from Global Positioning System satellites. Features include 
VMS software support, zero-latency interface, and automatic determination of type and po¬ 
larity of time code applied to it. Price: $9,500; with GPS receiver option, $12,500. 

Wireless LAN adapter card, credit-card size, designed for Compaq LTE Lite and LTE 
386SX/20 notebook computers operates with Novell NetWare 2.X, 3.11 Lite, Artisoft’s 
LANtastic, and the NDIS driver standard. Uses spread spectrum RF technology that doesn’t 
require FCC licensing. Features include 800-ft. range, 242-Kbps data rate, three full chan¬ 
nels, and communications with RangeLAN/ISA full-size adapter card. Price: $595. 

VME 32-bit bus link bridges NATO-4146C and Mil-Std-1397 types B, C, and H interfaces for 
Naval Tactical Data System. Provides full duplex differential I/O, 68020 processor, VIC-068 
interface, and on-board development tools. Price: $4,931 (commercial); $5,250 (ruggedized). 

Single-slot, multiuser, multiscreen accelerator for Sun Sparcstations or Sparc-compatible 
SBus workstations. Features a display dial for instantaneous change in monitor resolution 
from 1,152 x 900 to 640 x 480. Comes with SunOS CG3-compatible device driver, accelerated 
Open Windows XI 1/NeWS server, Weitec W8720 controller, 1-Mbyte 8-bit color frame buff¬ 
er, and Sun-4-style keyboard/mouse port. Uses 4 MBytes address space. Price: from $1,750. 

SBus board with two phone line interfaces, codecs, and Touch Tone support provides hard¬ 
ware for remote database access, voice mail, voice processing, speech recognition, and auto¬ 
mated attendant operation. In recording mode, audio data is received from a phone line, digi¬ 
tized, compressed, then stored as a file. Playback mode reverses the process. Includes a 
SunOS driver and downloadable code for the on-board 56001 DSP. Price: $1,350. 
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Partial support may be available to attend IFIP Congress 92 


The 12th World Computer Congress 
of the International Federation for In¬ 
formation Processing (IFIP) will be 
held in Madrid, Spain, September 7- 
11. The Federation on Computing in 
the United States (FOCUS) has re¬ 
quested a grant from the National Sci¬ 
ence Foundation to partially support 
attendance at IFIP Congress 92 by US 
computing professionals. 

If the grant is approved, FOCUS will 
be able to support travel for approxi¬ 
mately 50 attendees. Funding will be 
limited to $900 maximum per attendee. 

A review panel consisting of repre¬ 
sentatives from the FOCUS Board of 
Directors and other experts in the 


field will evaluate individual grant ap¬ 
plications. Applicants should provide 
the selection committee with a current 
resume and relevant details of their 
planned conference activities (that is, 
presenting papers, chairing sessions, 
serving as panel members, etc.) and/or 
how participation will benefit their 
current activities and research. 

All awardees must be residents in 
the US and travel by US carriers. In 
addition, they will be required to file a 
brief report following the conference 
on their activities and experiences at 
the congress. 

FOCUS, organized jointly by the 
ACM and the IEEE Computer Soci¬ 


ety, is the officially recognized US 
member of IFIP. Tom Cain, an associ¬ 
ate professor of electrical engineering 
at the University of Pittsburgh, was 
elected to chair the FOCUS Board of 
Directors for 1992. FOCUS provides a 
forum for its member societies to ex¬ 
change views about US and IFIP com¬ 
puting activities. Other societies dedi¬ 
cated to its purposes may apply for 
membership. 

Individuals wishing to submit appli¬ 
cations should contact FOCUS, 1730 
Massachusetts Ave. NW, Washington, 
DC 20036-1903; phone (202) 371-0101, 
fax (202) 728-9614, Internet e-mail ad¬ 
dress: grant@compmail.com. 



Late Magazines? 
No Magazines? 
Membership 
Status Problems? 
No Answers 
To Your 
Complaints? 

Let your 


cut 
through 
the red 
tape 
for you. 


Society presents Computer Entrepreneur Award 


J. Presper Eckert received the 
IEEE Computer Society’s 1990 Com¬ 
puter Entrepreneur Award April 8 at 
the 1992 IEEE VLSI Test Symposium 
in Atlantic City, New Jersey. Ned 
Kornfield, a member of the Sympo¬ 
sium Steering Committee and the 
Computer Society Awards Commit¬ 
tee, made the presentation at a special 
luncheon. 

The Computer Entrepreneur 
Award, which consists of an engraved 
sterling silver memento, is given annu¬ 
ally to visionaries whose entrepre¬ 
neurial efforts and leadership have re¬ 
sulted in the growth of a segment of 
the computer industry. Eckert is well 
known throughout the industry for 
both his entrepreneurial and his pio¬ 
neering activities. He has received na¬ 
tional recognition for his contribu¬ 
tions to the computer industry — 
most notably the National Science 
Medal, presented by President Lyn¬ 
don Johnson. 

Eckert and colleague John Mauch- 
ly, working at the University of Penn¬ 
sylvania, were the key designers of the 
ENIAC, the world’s first large-scale 
electronic general-purpose digital 
computer. They later formed the Eck- 
ert-Mauchly Computer Corp., which 
was subsequently merged into Sperry- 
Rand as the Univac Division. Eckert 


recently retired as a vice president of 
the corporation. 

After accepting the award, Eckert 
summarized his experiences with the 
ENIAC program and the subsequent 
and sometimes difficult steps taken to 
develop the commercial version of the 
equipment. 

Following the presentation, 1992 
IEEE President Merrill W. Buckley 
Jr. spoke to symposium attendees on 
the role of the engineer in the world 
economy and the closely related top¬ 
ics of engineering manpower and in¬ 
novation. Both Buckley and Eckert 
responded to questions from the audi¬ 
ence. 


Erratum 

IEEE Computer Society Pioneer 
Award winner Thomas E. Kurtz 
was incorrectly reported to have 
served as president of Dartmouth 
College from 1970 to 1981 ( Com¬ 
puter , May 1992, p. 91). In fact, it 
was Kurtz’s colleague John G. Ke- 
meny who held that office. We re¬ 
gret the error. 
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Send news about research, public policy, or professional issues to Bob Carlson, Computer, 
10662 Los Vaqueros Circle, PO Box 3014, Los Alamitos, CA 90720-1264 


Firms pursue neural network innovations 


Recent announcements from Bell¬ 
core and Toshiba describe progress 
the two firms are making in the devel¬ 
opment of artificial neural networks. 
Toshiba’s R&D center reports that re¬ 
searchers have developed and proved 
the practicality of two basic mecha¬ 
nisms for connecting and controlling 
neural network modules. Bellcore’s 
researchers have created a computer 
that can learn and process patterns in 
more than 100,000 individual signals 
each second. 

Toshiba investigates Amari- 
Hopfield network. Confronting the 
main problems in expanding the scale 
of associative networks — how to con¬ 
nect multiple modules in a multilay¬ 
ered structure and how to control 
their interaction — Toshiba research¬ 
ers have developed methods that al¬ 
low incremental increases in network 
size as well as interaction between 
component modules and enhanced 
processing speed. 

Two basic mechanisms for connec¬ 
tion and control were developed and 
tested for practicality. The first pre¬ 
vents a data processing error in one 
module from causing deterioration of 
performance in an associative net¬ 
work. A module asked to recognize 
something it is not programmed to 
know may produce false output; it 
also takes longer to arrive at its out¬ 
put. Researchers used this latter char¬ 
acteristic to develop an error control 
mechanism that tells the module to 
output zero if it is slow to process a 
response. This prevents errors from 
entering the whole system. 

The second mechanism permits co- 
operative-competitive interaction of 
associated modules in a multilayered 
structure. Faced with the impossibility 
of interaction between modules in the 
one-layered Amari-Hopfield network, 
Toshiba researchers proposed a multi¬ 
layer representation with an input lay¬ 
er and hidden layers that provide the 
interface. They report that such a 
method requires no additional control 
procedures. 

Bellcore’s learning computer. An 

updated version of an experimental 
chip that Bellcore first demonstrated 


in 1988 processes information by us¬ 
ing electronic versions of 496 synapses 
and 32 neurons. So that the chip does 
not get “stuck” on its way to making a 
decision, special electronic structures 
on the chip prod neurons with elec¬ 
tronic noise, encouraging the chip to 
make a good decision. Because the 
chip is cascadable, it can be linked to 
others just like it to make a larger sys¬ 
tem capable of processing more infor¬ 
mation faster. 

The prototype computer’s current 


The US Department of Defense has 
awarded a five-year, $4.3-million 
grant to a University of Illinois re¬ 
search group to build electronic devic¬ 
es on the scale of atoms. The chal¬ 
lenge is to create methods that will 
speed development of ever smaller 
computer components. Using current 
methods, such reductions in size are 
expected to reach a dead end by the 
close of the decade. 

Researchers hope to turn the rela¬ 
tively new technique called nano¬ 
lithography — patterning done on an 
atomic scale — from a laboratory cu¬ 
riosity into a manufacturing possibili¬ 
ty. To achieve their goal, the research 
group will use a tool called a scan¬ 
ning-tunneling microscope (STM), 
which functions like a record player’s 
tone arm but with a stylus sensitive 
enough to detect individual atoms. 

The tip of the tunneling probe can 
not only detect but also move atoms 
by prodding them. In addition, the 
electric field at the tip of the probe 
can trigger chemical reactions, an ef¬ 
fect that opens the possibility of pat¬ 
terning circuits on a very small scale. 

Several problems must be overcome 
to create a practical new technology. 
The group must develop the tunneling 
microscope’s capability to view a rela¬ 
tively large area — a kind of aerial 
perspective — while maintaining its 
fine, close-up resolution. Also needed 
is the capability to move the micro¬ 
scope’s scanning area without the loss 


high speed is attributed to its parallel, 
rather than serial, operation. Re¬ 
searchers plan to add more chips to 
the prototype to create an experimen¬ 
tal neural learning computer aimed at 
solving problems commonly faced in 
telecommunications network manage¬ 
ment and operations systems, includ¬ 
ing routing telephone calls, assigning 
frequencies to wireless equipment, 
compressing telephone company busi¬ 
ness data for storage and transmis¬ 
sion, and recognizing speech. 


of image resolution through vibration. 
Project director Joseph Lyding, a 
member of the university’s multidisci¬ 
plinary Beckman Institute for Ad¬ 
vanced Science and Technology, holds 
a patent dealing with the first problem 
and has applied for one on the second. 

In addition to Lyding, the research 
group includes — also from the Uni¬ 
versity of Illinois — Ilesanmi Adesida, 
who will work on the etching process, 
combining scanning-tunneling lithog¬ 
raphy with other methods; Stephen 
Bishop, who is developing very small 
device characterization techniques 
that combine scanning-tunneling mi¬ 
croscopy with optical techniques; K.Y. 
Cheng, an expert in growing semicon¬ 
ductor substrates, or underlying lay¬ 
ers, through a technique called molec¬ 
ular beam epitaxy, a method for 
depositing atoms in very thin layers; 
Karl Hess, a specialist in supercom¬ 
puter simulations; and Minir Nayfeh, 
who will work on methods for laser- 
assisted STM lithography. Additional 
group members Stephen Campbell 
and Ted K. Higman of the University 
of Minnesota are fabricating conven¬ 
tional devices specifically designed to 
incorporate modifications achieved by 
STM nanolithography. 

Industry will have immediate access 
to the research through an industrial 
affiliates program. “We’ll do every¬ 
thing we can to make sure industry as¬ 
similates our relevant results as soon 
as possible,” Lyding said. 


Researchers receive grant to think small 
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Editor: Norman F. Schneidewind, Naval Postgraduate School, Code AS/Ss, Monterey, CA 93943, fax (408) 646-3407, 

e-mail 0422p@cc.nps.navy.mii 


A standard for software maintenance 


A framework for managing and executing software maintenance activities 

D. Vera Edelstein and Salvatore Mamone, Nynex Science and Technology 


Maintenance is usually the part of 
the software life cycle delegated to 
low-level programmers. Many organi¬ 
zations don’t even use the word main¬ 
tenance. They regard the correction, 
perfection, and adaptation of systems 
as either support or development. 1 
Such names imply more meaningful 
work than just maintenance. In this 
article, we explain why we believe a 
maintenance standard is needed and 
the ways in which the IEEE P1219 
Working Group for Software Mainte¬ 
nance is attempting to standardize the 
maintenance process. 

Maintenance can be defined as any 
change to a system after it is opera¬ 
tional. Such changes can be required 
because of 

• errors (corrective), 

• a modified environment (adap¬ 
tive), or 

• a need to improve performance, 
maintainability, or functionality 
(perfective). 

We can also add emergency mainte¬ 
nance to this list as a subset of correc¬ 
tive maintenance. Although emergen¬ 
cy maintenance is generally abnormal, 
the problem needs to be integrated 
into the normal maintenance process. 

Maintenance generally has been 
considered the last phase of a soft¬ 
ware product’s life cycle, as shown in 
the waterfall 2 and other models. 3 Plan¬ 
ning for maintenance should, how¬ 
ever, take place concurrently with de¬ 
velopment. When maintenance is 
considered a phase or a step, planning 
seldom occurs. Producing the product 
becomes the objective. As stated 
above, changes are for “low level” 
programmers and staff to make. 4 

Discussions of original development 
often include the use of structured 
techniques. The expectation is that us¬ 
ing structured techniques will make 
systems easier to develop, understand, 
and maintain. Maintainability is, 
therefore, looked upon as a result of 


structured techniques. Instead, it 
should be regarded as a characteristic 
of software. 

The objective of maintenance is the 
modification of an existing system. 
Since systems usually have to be 
changed, planning for maintenance si¬ 
multaneously with development is im¬ 
perative. Even if a new operational 
system has zero defects, we can expect 
changes to occur. Environments 
change, and enhancements are often 
required. Legal requirements and 
competition may also dictate changes 
to an operational system. Moreover, 
we expect all of these changes to oc¬ 
cur on a regular basis. Planning for 
them ensures quality control of the 
change process. 

Is a software standard necessary? 

Every software product is different. It 
can differ in size, scope, and technolo¬ 
gy used. It might be a product devel¬ 
oped a long time ago, or it might be 
brand new. With such diversity, why 
try to standardize software mainte¬ 
nance at all? 

The IEEE P1219 Working Group is 
creating a standard to address the 
problem of software maintenance that 
faces all corporations. The size and 
complexity of systems under mainte¬ 
nance are growing. 5 Because mainte¬ 
nance consumes so much of a corpora¬ 
tion’s data processing budget, 
relatively little new development is 
taking place. Between 30 and 80 per¬ 
cent of all software development costs 
are spent on maintenance. 6 8 Accord¬ 
ing to Fletcher Buckley, “The amount 
of code to be maintained is rapidly ap¬ 
proaching the point where it will con¬ 
sume all the available work force.” 9 
Although many practitioners and aca¬ 
demicians claim that software mainte¬ 
nance is just an extension or repeti¬ 
tion of initial development, there are 
enough significant differences be¬ 
tween original development and main¬ 
tenance to justify the creation of a 
maintenance standard. 


Original development of a system 
implies the absence of an existing sys¬ 
tem. Usually, it also implies that a 
longer time frame is needed for imple¬ 
mentation. In addition, it is usually fi¬ 
nanced by the developer, while main¬ 
tenance is usually financed by the 
user. Development of a new system 
generally involves a large staff and ex¬ 
tended resources. 

Software maintenance is performed 
on an existing system, and its changes 
must conform to an existing architec¬ 
ture, design, and code. Whereas origi¬ 
nal development can span years, 
maintenance can span from hours (for 
emergency maintenance) to months. 
Maintenance testing usually differs 
from testing done for original devel¬ 
opment. New systems require a test¬ 
bed with test cases specific to the sys¬ 
tem and system requirements. 
Ordinarily built from scratch, these 
test cases, or a subset (“bucket”) of 
them, must be measured against a 
modified system to verify that the 
change has not created unwanted side 
effects. 

The P1219 standard. We believe 
most members of the computing com¬ 
munity would agree that a mainte¬ 
nance standard is needed to bring 
consistency to the maintenance pro¬ 
cess and to shorten the time necessary 
to perform maintenance. A standard 
for software maintenance will provide 
powerful help to those who prefer to 
keep large and complicated software 
systems operational irrespective of 
their age. When adopted, the standard 
will also provide software engineers 
with a framework containing precise 
terminology and processes for the 
consistent application of technology 
(tools, techniques, and methods) to 
solve software maintenance prob¬ 
lems. 

The P1219 standard will provide the 
framework within which generic and 
specific software maintenance plans 
can be executed, evaluated, and tai- 
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lored to a given project. The standard 
comprises three sections: 

• the standard, or the required in¬ 
formation pertaining to the main¬ 
tenance process; 

• maintenance guidelines, that is, 
additional information not re¬ 
quired for conformance; and 

• supporting maintenance technology. 


The last two sections are appendixes 
to the standard. 

Standard sections. The required in¬ 
formation in the standard will delin¬ 
eate all the steps involved in software 
maintenance. This section includes 
the input and outputs required for the 
seven stages of maintenance: 

• problem/modification, identifica¬ 
tion, and classification, 

• analysis, 

• design, 

• implementation, 

• system testing, 

• acceptance testing, and 

• delivery. 

Although the names of these stages 
are similar to those of original devel¬ 
opment, the input, output, and pro¬ 
cess of maintenance are not the same. 

In addition to the inputs and out¬ 
puts, the standard will identify the 
control issues generic to maintenance. 
The standard will establish the control 
mechanism that exists within each 
stage of the maintenance cycle. These 
controls define what is needed to con¬ 
vert the input of the phase to the re¬ 
quired output. 

Maintenance guidelines. The main¬ 
tenance guidelines will describe the 
following issues: 

• the maintenance process itself, 

• maintenance planning, including 
development of a maintenance 
plan, 

• maintenance forms, such as the 
software change request, 

• validation and verification, 

• quality assurance, 

• risk assessment, 

• safety, 

• security, 

• configuration management, 

• metrics, and 

• the software replacement policy. 

The final section will identify topics 
that should be addressed when deter¬ 
mining whether to modify a system or 
replace it. This section will also detail 


the economic consequences of re¬ 
placement. 

Supporting maintenance technology. 
The supporting maintenance technol¬ 
ogy appendix will include 

• reengineering, 

• reverse engineering, 

• holistic reuse, and 

• software tools. 

The section on reverse engineering 
will identify the process and describe 
how large systems with little docu¬ 
mentation can be maintained via re¬ 
verse engineering. Mapping the re¬ 
verse engineering method to software, 
we are able to transform an unmain¬ 
tainable system into one that is main¬ 
tainable. 4 The software-tools section 
will list generic tools and methods 
that can be used for maintenance and 
will examine when they should be 
used. No vendor product will be iden¬ 
tified or endorsed. 

Conclusions. As stated above, we 
need a standard that will prompt con¬ 
sistency in the maintenance process 
and shorten maintenance time re¬ 
quirements. Due to the magnitude of 
maintenance, it is important that orga¬ 
nizations standardize the process. De¬ 
spite certain similarities, original de¬ 
velopment and maintenance are 
different. By standardizing for main¬ 
tenance, organizations can reduce the 
time and resources needed to perform 
changes, while bringing quality to the 
process. 

The P1219 standard has been sub¬ 
mitted for balloting, a balloting group 
has been formed, and ballot results 
and comments are expected this 
month. Modification of the standard 
reflecting reviewer comments is 
scheduled during the third quarter of 
this year, and the standard is expected 
to be adopted in early 1993. 

For additional information, contact 
either author at Nynex Science and 
Technology Inc., 500 Westchester 
Ave., White Plains, NY 10604. 
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Two Working Group 
P1059 meetings set 

IEEE Working Group P1059, near¬ 
ing completion of work on its Guide 
to Software Verification Plans, will 
meet in Dallas June 23-25 and Hous¬ 
ton September 22-24. Once adopted, 
the guide is expected to be a compan¬ 
ion document to IEEE-Std-1012-1986, 
“IEEE Standard for Software Verifi¬ 
cation and Validation Plans.” 

Jerry Mersky, who chairs the work¬ 
ing group, said he believes the guide 
will go to ballot in early 1993. 

Anyone interested in receiving fu¬ 
ture drafts and information about fu¬ 
ture meetings or in commenting on 
existing materials should contact Jerry 
Mersky, Logicon, 222 W. Sixth St., 

San Pedro, CA 90733-0471, phone 
(310) 831-0611, ext. 2471. 


Draft report available 

The American National Standards 
Committee on Pascal, X3J9, will have 
the draft version of a technical report 
on object-oriented extensions to Pas¬ 
cal available in July. 

Anyone interested in obtaining a 
copy of the draft for review and com¬ 
ment should contact Thomas N. Tur- 
ba, Unisys, MS 4672, PO Box 64942, 
St. Paul, MN 55164-0942, phone (612) 
635-6774, fax (612) 635-3899, net 
turba@rsvl.unisys.com. 
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CAREER OPPORTUNITIES 


RATES: $15.00 per line (ten lines 
minimum). Average five typeset words 
per line, eight lines per column inch. Add 
$10 for box number. Send copy at least 
one month prior to publication date to: 
Marian B. Tibayan, Classified 
Advertising, COMPUTER Magazine, 
10662 Los Vaqueros Circle, PO Box 
3014, Los Alamitos, CA 90720-1264; 
(714) 821-8380; fax: (714) 821-4010. 

In order to conform to the Age Discrimina¬ 
tion in Employment Act and to discourage 
age discrimination, COMPUTER may re¬ 
ject any advertisement containing any of 
these phrases or similar ones: “...recent 
college grads...,” “...1-4 years maximum 
experience...,” “...up to 5 years experi¬ 
ence,” or “...10 years maximum experi¬ 
ence.” COMPUTER reserves the right to 
append to any advertisement without spe¬ 
cific notice to the advertiser. Experience 
ranges are suggested minimum require¬ 
ments, not maximums. COMPUTER as¬ 
sumes that since advertisers have been 
notified of this policy in advance, they 
agree that any experience requirements, 
whether stated as ranges or otherwise, will 
be construed by the reader as minimum re¬ 
quirements only. COMPUTER encour¬ 
ages employers to offer salaries that are 
competitive, but occasionally a salary may 
be offered that is significantly below cur- 
rendy acceptable levels. In such cases the 
reader may wish to inquire of the employer 
whether extenuating circumstances apply. 


OPERATIONS RESEARCH ANALYST 

Operations Research Analyst required. 
Design and development and analysis of 
mathematical programming, optimization 
algorithms and mathematical models in sup¬ 
port of decision forecasting systems. Perform 
techniques as mathematical programming 
inventory control, queuing theory, sequenc¬ 
ing, scheduling and stochastic modeling, 
Linear and Non-Linear Programming in C, 
FORTRAN, and X-Windows/MOTIF in 
UNIX, VMS & DOS operating environ¬ 
ments. Applicants required to have a 
Masters Degree or its equivalent in an 
Operations Research curriculum with at least 
one year experience in the job offered. 
Graduate project/research work will be ac¬ 
ceptable to satisfy the 1 year experience re¬ 
quirement. Salary will be $36,000/year for a 
40-hour work week. Must have proof of 
legal authority to work in the U.S. Interested 
applicants apply at the Texas Employment 
Commission, Ft. Worth, TX, or send re¬ 
sume to the Texas Employment Commis¬ 
sion, Austin, TX 78778-0001, J.O. Number 
6521670. This advertisement was paid by an 
Equal Opportunity Employment employer. 


DEVELOPMENT STAFF MEMBER 

Conduct research and development efforts 
in the field of Multi-Protocol Transport Net¬ 
working. Investigate new ways of transport¬ 
ing multiple protocols across many different 
types of communication networks. Specific¬ 
ally, responsibility will be to participate in the 
research and development of a Multi Proto¬ 
col Transport Network prototype for AIX, 
OS/2, and MVS environments. 40 hrs./wk., 
$58,000/yr. Must have Ph.D. in computer 
science, and 1 year experience on the job or 
1 year experience as a pre or post doctoral 
research associate/or researcher. The 1 year 
experience must include research in protocol 
conversion and networks interconnection; 
design and analysis of high performance 
switches for high speed networks as well as 
SNA, TCP/IP, OSI protocols. Please apply 
to your nearest Job Service Office or send 
resume to Job Service, 516 N. Mangum St., 
Durham, NC 27701. All resumes must in¬ 
clude Social Security number, Job Order No. 
NC 3012067, and DOI Code 030.062-010. 


UNIVERSITY OF OREGON 

The Department of Computer and Infor¬ 
mation Science invites applications for a 
senior faculty position created by a new state 
Centers of Excellence award. We are seek¬ 
ing a person who will be an active leader in 
the department, willing to serve a term as 
department head and also play a key role in 
relations to the computer industry. Appli¬ 
cants should have a Ph.D. in computer sci¬ 
ence or related field and a distinguished 
record of teaching and research in the area 
of parallel processing (including parallel 
architectures, languages, and performance 
modeling) or human-computer interaction 
(including computer graphics and scientific 
visualization). Our department has 14 other 
research faculty positions (including one 
other new position for which we are current¬ 
ly recruiting), approximately 20 Ph.D. stu¬ 
dents, 50 M.S. students, and 150 B.S. stu¬ 
dents. We have strong research programs in 
parallel and distributed systems, computer 
graphics, user interfaces, programming lan¬ 
guages, software engineering, artificial in¬ 
telligence, and theoretical computer science, 
and active interdisciplinary ties with other 
on-campus groups in the fields of cognitive 
science, neuroscience, economics, biology, 
physics, and mathematics. We offer a modern 
computing environment (a MasPar MP- 
1100, two Sequent Symmetry multiproces¬ 
sors, and dozens of Sun and HP worksta¬ 
tions) housed in a new computer science 
building. 

Review of applications will continue until 
the position if filled. The position is available 
September 1992, with a target date for filling 
the position by January 1993. Qualified ap¬ 
plicants should send their curriculum vitae 


and the names of at least three references to: 
Professor John Conery, Faculty Search 
Committee, Department of Computer and 
Information Science, University of Oregon, 
Eugene, OR, 97403-1202. For more infor¬ 
mation send e-mail to conery@cs.uoregon. 
edu or phone (503) 346-3973. The Univer¬ 
sity of Oregon is an Equal Opportunity/Af¬ 
firmative Action Employer committed to 
cultural diversity. We especially encourage 
applications from women and minorities. 


COMPUTER SYSTEMS SPECIALIST 

Computer Systems Specialist to be desig¬ 
nated as system maintenance manager for 
computer consulting firm. Duties include 
directing team of systems analysts in solving 
technical and business problems by com¬ 
puter. Will interface with functional users of 
system and EDP staff concerning current in¬ 
stallation and resolve problems with man¬ 
agement and functional users of the system. 
Must have BS in computer or engineering 
sciences and five years experience as 
systems analyst or software engineer with 
knowledge and involvement in OPNS and 
maintenance industry applications. Must 
have knowledge of Mini, Micro and Main¬ 
frame. Salary $44K/yr. Job site and inter¬ 
view, Evergreen, Colorado. Apply by re¬ 
sume to: Colorado Dept, of Labor and Em¬ 
ployment, 600 Grant St., *900, Denver, 
CO 80203-3528, Attn: Employment Pro¬ 
gram, Job Order »C03773898, no later 
than 7/1/92. 


RESEARCH ASSISTANT PROFESSOR 

Research Assistant Professor in Computer 
Science needed to study computer aided 
prototyping. Salary $50,000.00 per year. 
Require a Ph.D. Degree in Computer Sci¬ 
ence and 1) Knowledge of: Descriptive Geo¬ 
metry, Engineering Drawing, Production 
Engineering, Electrical Engineering and 
Electronics, Mechanics, Probability Theory, 
Digital Signal Processing, Operations Re¬ 
search, Information Theory, and Optimiza¬ 
tion Theory, 2) Research background in 
robotics, computer vision, automation, ar¬ 
tificial intelligence, computer aided control 
system design, signal processing and sys¬ 
tems engineering, active observation and 
discrete event dynamic system modeling for 
observers under uncertainty, addressing 
controllability and observability issues, as 
demonstrated by significant scholarly publi¬ 
cations, and doctoral research. Job Order 
No. 2819402. Contact Utah Job Service 
5735 South Redwood Road, P.O. Box 
11750, Salt Lake City, Utah 84147-0750. 
Employer is an EEO/AA Employer. 
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SYSTEMS DESIGN ENGINEER 

Systems Design Engineer required. De¬ 
sign, programming, monitoring and analysis 
of computer architecture and computer 
operating systems using: UNIX/C, Fortran, 
low-level UNIX kernel programming, as¬ 
sembly programming, assembly instruction 
scheduling, assembly optimization techni¬ 
ques, distributed concurrency control 
algorithms and UNIX system code mainte¬ 
nance development. Extensive work with 
scheduling and parallel processing algo¬ 
rithms, computer architectures and com¬ 
pilers. Work with UNIX, DOS and VMS 
operating systems. Applicants required to 
have a Masters Degree or its equivalent in 
Computer Science with at least one year ex¬ 
perience in the job offered. Graduate project 
research work in this area will be acceptable. 
Salary will be $36,000/year for a 40-hour 
work week. Must have proof of legal authori¬ 
ty to work in the U.S. Interested applicants 
apply at the Texas Employment Commis¬ 
sion, Ft. Worth, TX, or send resume to the 
Texas Employment Commission, Austin, 
TX 78778-0001, J.O. #6521664. This ad¬ 
vertisement was paid by an Equal Oppor¬ 
tunity Employment employer. 


UNIVERSITY OF SOUTH FLORIDA 

Department of Computer Science 
and Engineering 

The Department of Computer Science 
and Engineering is seeking applicants for 
a visiting faculty position at the Sarasota 
Campus starting Fall Semester, 1992. The 
Department offers bachelor’s degrees in 
Computer Science, Computer Engineering, 
and Information Systems, and has Master’s 
and Ph.D. programs in Computer Science 
and Engineering. 

The University of South Florida, with an 
enrollment of more than thirty-three thou¬ 
sand, is the second largest institution in the 
State University System. The main campus 
is located in Tampa, the principal city of 
dynamic West Central Florida. The Sarasota 
campus is located sixty-five miles south of 
Tampa in an area known for its cultural 
resources. The University operates an in¬ 
teractive instructional television network that 
links the Tampa, Sarasota, St. Petersburg 
and Lakeland campuses and a large number 
of industrial sites. 

The Department is headquartered in a 
new twelve million dollar building which it 
shares with the Department of Electrical 
Engineering on the Tampa Campus. All of 
the present fifteen full-time faculty members 
are assigned to the Tampa campus. The suc¬ 
cessful applicant will be assigned to the 
Sarasota campus and will engage in under¬ 
graduate teaching, advising and research. 
Travel between the Sarasota and Tampa 
campuses and substantial departmental in¬ 
teraction will be required. The Department 
research network includes a substantial 
number of SUN, DEC and IBM worksta¬ 
tions, an INTEL 2/386 hypercube, and a 
variety of specialized graphics and image 
processing equipment. Additional comput¬ 
ing resources are available on the College 
computing network and the University net¬ 


work. All three networks are accessible on 
the Sarasota campus. Some specialized 
equipment is accessible only on the Tampa 
campus. The departmental faculty are ac¬ 
tively engaged in research activities sup¬ 
ported by federal, state and industrial 
sources. There is industrial interaction with 
a number of companies in West Central 
Florida including AT&T, E-Systems, GTE 
Data Services, Group Technologies, Harris, 
Hercules, Honeywell and IBM. 

Applicants should send an updated resume 
and arrange to have three letters of reference 
sent to Faculty Search Committee, Compu¬ 
ter Science and Engineering, University of 
South Florida, Tampa, Florida 33620. 

The University of South Florida is an equal 
opportunity and affirmative action employer. 


THE UNIVERSITY OF TENNESSEE 

Department of Computer Science 

Knoxville, Tennessee 37996-1301 

The Department of Computer Science 
seeks to fill one tenure-track faculty position 
at the rank of Professor, Associate Professor 
or Assistant Professor, as credentials war¬ 
rant, beginning Fall 1992. For a full- 
professorship , a strong research record in the 
areas of operating systems, scientific com¬ 
puting or software engineering is sought but 
all major fields in computer science may be 
considered. Experience directing doctoral 
students is especially important. Applicants 
for Associate Professor should have a strong 
research record, preferably in the above- 
named areas; experience directing doctoral 
students is desirable. Applicants for Assistant 
Professor should have a strong interest in 
research, preferably in the above-named 
areas. Applicants for all positions should 
have a doctoral degree in computer science 
or a related area. Applicants should specify 
the rank for which they are applying. 

Departmental SUN, IBM and DEC work¬ 
stations abound for students and faculty and 
are fully networked. In addition, the depart¬ 
ment has acquired a Thinking Machine CM-5. 
The department and the Mathematical Sci¬ 
ences Section of the Oak Ridge National 
Laboratory jointly operate the Advanced 
Computing Laboratory which includes fully 
networked Intel iPSC/860, 128 processors; 
iPSC/2, 64 processors; two Sequent Bal¬ 
ances and a Sequent Symmetry; a Stardent 
Titan with four processors; Cogent; N-Cube; 
Kendall Square Research machine with 32 
processors; and various file servers. Also, 
Oak Ridge National Laboratory is acquiring 
an Intel Paragon. In addition, the depart¬ 
ment has recently received an NSF Small- 
Scale Infrastructure Award. The department 
is part of the National Science Foundation 
Science and Technology center for Research 
in Parallel Computing. The University oper¬ 
ates an IBM 3090 and a large VAX cluster. 

Please respond to search@cs.utk.edu. 
The mailing address is Search Coordinator, 
Department of Computer Science, 107 Ayres 
Hall, The University of Tennessee, Knoxville 
TN 37996-1301. 

The University of Tennessee is an EEO/ 
AA/TITLE 1X/SECTION 504/ADA 
employer. 


UNIX/C SOFTWARE ENGINEER 

UNIX/C Software Engineer required. De¬ 
sign, develop and implement hardware con¬ 
figurations and custom software applications 
based on analysis of user needs. Program¬ 
ming in Fortran, C, DOS batch, UNIX shell 
script, RISC assembly and Intel 80x86 
assembly plus Kernel File System Protocol. 
Operation system development: UNIX and 
AIX (system calls), and DOS (system calls, 
interrupt handlers). Utilize knowledge of 
architecture, repairing and configuring the 
following hardware: IBM-PC (386 & 486), 
RISC-based machines, PDP-11, Tape 
Drives, Floppy Drives, Laser Disc Drives, 
Memory Boards, Modems (1200, 2400 & 
9600 Baud), and both parallel and serial 
protocol printers. Configure emulation 
packages to allow IBM PC’s to interface as 
terminals with DEC environment systems. 
Applicants required to have a Bachelor’s 
Degree in Computers or Engineering with at 
least two years experience in the job duties 
listed above. Must have proof of legal 
authority to work in the U.S. An annual 
salary of $33,000 will be paid for a 40-hour 
work week. Interested applicants apply at 
the Texas Employment Commission, Ft. 
Worth, TX, or send resume to the Texas 
Employment Commission, Austin, TX 
78778-0001, J.O. #6687561. This adver¬ 
tisement was paid by an equal opportunity 
employment employer. 


UNIVERSITY OF BRITISH COLUMBIA 
The Department of 
Electrical Engineering 

The Department of Electrical Engineering, 
University of British Columbia invites appli¬ 
cations for a tenure-track Assistant Professor 
appointment in Computer Engineering. Soft¬ 
ware engineering, including real-time ap¬ 
plications, is of primary interest, although 
applications in other areas of computer engi¬ 
neering are encouraged. A Ph.D. is required. 
Industrial and/or teaching experience 
would be useful. The successful applicant 
would be expected to pursue research vigor¬ 
ously, and to teach at the graduate and 
undergraduate levels. Collaboration with the 
Department of Computer Science is facili¬ 
tated through the Centre for Integrated 
Computer Systems Research. Salary is com¬ 
mensurate with qualifications and experi¬ 
ence. Start-up funding is available for pur¬ 
chase of equipment and support of graduate 
student research assistants. The position is 
available from July 1, 1992. Priority will be 
given to applications received on or before 
July 31, 1992. To apply, send curriculum 
vitae, reprints of published papers, and 
names of at least three references, and state 
eligibility for employment in Canada to: Dr. 
R.W. Donaldson, Head, Department of 
Electrical Engineering, The University of 
British Columbia, 2356 Main Mall, Van¬ 
couver, B.C. Canada V6T 1Z4. The Univer¬ 
sity of British Columbia encourages qualified 
women and minority applicants. In accor¬ 
dance with Canadian Immigration require¬ 
ments, priority will be given to Canadian 
citizens and permanent residents of Canada. 
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SENIOR COMPUTER SCIENTIST 

RAND is seeking a senior computer scien¬ 
tist for its Santa Monica location to lead 
research in one of its areas of advanced com¬ 
puting research, which emphasize, but are 
not necessarily limited to, modeling, simula¬ 
tion and visualization. A successful candidate 
will have an established research reputation 
with a demonstrated capacity to lead com¬ 
puting research. A Ph.D. in computing or 
related field is necessary plus an ability to 
work collaboratively with researchers in 
other disciplines. Candidate should also 
have extensive knowledge of the computing 
and communications disciplines, and 
familiarity with the major governmental 
agencies sponsoring research in these areas. 
RAND is a private, non-profit research in¬ 
stitution engaged in research and analysis of 
matters affecting national security and the 
public welfare. U.S. citizenship required. 
Address applications to: Anthony C. Hearn. 

RAND 

1700 Main Street 
P.O. Box 2138 

Santa Monica, CA 90407-2138 
An Affirmative Action Employer. 


COLORADO STATE UNIVERSITY 
Department of Electrical Engineering 
Research Opportunities in 

Microelectronics and VLSI Design 

The Department of Electrical Engineering 
at Colorado State University has an opening 
for a highly-qualified Ph.D. candidate or 
Research Associate in microelectronics and 
VLSI design starting August 20, 1992. Cur¬ 
rent research activities include self-testing 
and self-repairing memory architectures for 
future 256 Mb - 1 Gb memory chips, fault- 
tolerant massive parallel processing architec¬ 
tures for DSP and general-purpose comput¬ 
ing, neural chip architectures, modeling and 
design of MCM systems, and CAD tech¬ 
niques for VLSI design. 

The Department of Electrical Engineering 
has state-of-the-art VLSI design and pro¬ 
cessing labs equipped with HP700 and 400 
series workstations and Mentor Graphics 
EDA tools. High technology corporations 
such as Hewlett-Packard and NCR Micro¬ 
electronics have major operations in the area 
and provide support for the microelectronics 
and VLSI design programs. Located at the 
foothills of the Rocky Mountains, 60 miles 
north of Denver, CSU and the City of Fort 
Collins offer a beautiful environment and 
many outdoor activities. 

A successful Ph.D. candidate will have a 
M.S. in Electrical Engineering or related 
areas and will receive a monthly stipend and 
paid tuition. A Research Associate candidate 
will have a Ph.D. or M.S. with substantial 
research experience in the related areas. 
Salary will commensurate for the position 
and related experience. 

Reply to Dr. Tom Chen, Department of 
Electrical Engineering, Colorado State Uni¬ 
versity, Fort Collins, CO 80523. Telephone: 
(303) 491-6574. FAX: (303) 491-2249. 
Colorado State is an EOE/AA employer. 
E.O. Office: Room 21 Spruce Hall. 


MISSISSIPPI STATE UNIVERSITY 
Faculty Position 
Parallel Computing 
(Software Emphasis) 
Department of Computer Science and 

NSF Engineering Research Center 

Applications for a tenure-track computer 
science faculty position beginning Fall, 1992, 
are invited in the area of parallel computing, 
specifically in the software development and 
algorithmic aspects of parallel computing. 
Applicants at any level will be considered. 
Funding for research is available through the 
association with the National Science Foun¬ 
dation Engineering Research Center (NSF 
ERC). 

The NSF and Mississippi State University 
established the NSF ERC to develop an in¬ 
tegrated computational simulation system 
for large-scale field problems involving com¬ 
plex geometry and physics. A primary objec¬ 
tive of the NSF ERC is to provide U.S. in¬ 
dustry with such a simulation system for 
engineering design and applications. The 
approach is through a synergistic research 
program involving cross-disciplinary re¬ 
search and instruction in computational 
engineering, computer engineering, and 
computer science. A particularly important 
project of the ERC is to develop parallel algo¬ 
rithms and architectures to apply to com¬ 
putational field simulation problems. The 
NSF ERC has a 32-node Intel iPSC/860 to 
support parallel processing for computa¬ 
tional field simulation. 

A Ph. D. degree in Computer Science or a 
closely related field is required, and at least 
one year’s experience in research having to 
do with the software aspects of parallel com¬ 
puting is highly desirable. An established 
record of publication of research, or excep¬ 
tional potential in a new graduate, will be a 
primary consideration. Applicants are ex¬ 
pected to have strong commitments to both 
research and teaching, with experience and 
productivity in both areas strongly encour¬ 
aged. The successful applicant will par¬ 
ticipate in the research of the NSF ERC for 
Computational Field Simulation, and be ac¬ 
tive in departmental affairs. MSU has an ac¬ 
credited undergraduate program, and both 
masters and Ph.D. graduate programs. In¬ 
terested individuals should forward a vita 
and names of at least three references to: 

D.W. Dearholt, Head 

Department of Computer Science, 

Drawer CS 

Mississippi State, MS 39762 

Applications will be accepted through July 
2, 1992, or until position is filled. MSU is an 
Affirmative Action/Equal Opportunity 
Employer. 


SOFTWARE JOBS ABROAD 

The International Computer Professional 
Association provides you with the worldwide 
contacts and up-to-the-moment information 
you need to find an exciting software assign¬ 
ment in Paris, London, and many other cities 
around the world. For more information 
about this new global network of interna¬ 
tional opportunities call us at (415) 695-7618, 
24 hours/day. 


D.E. SHAW & CO. 

Algorithmic Trading 

D.E. Shaw & Co. is a small (several dozen 
employees), highly capitalized (over $300 
million in partners’ equity), extremely suc¬ 
cessful Wall Street firm specializing in quan¬ 
titative finance and computational trading. 
Computer scientists and system designers 
form the professional core of the firm, and 
not merely its support staff, and participate in 
its profits. Our technical staff includes both 
Ph.D.-level researchers recruited from Stan¬ 
ford, MIT, and other leading computer sci¬ 
ence departments and extraordinarily talented 
B.S.-and M.S.-level system designers and 
“superhackers”. It is our practice to compen¬ 
sate unusually gifted individuals at a level ex¬ 
ceeding that of the market. Applicants should 
send resumes to The Recruiting Depart¬ 
ment, D.E. Shaw & Co., 39th Floor, Tower 
45, 120 W. 45th St., New York, NY 10036. 


APPLICATION ENGINEER 

Duties: Contribution to design and imple¬ 
mentation of an object-oriented data model 
in the context of multi-media user interfaces. 
Design and implementation of an adequate, 
object-oriented query language including 
meta-data level queries, semantics of the 
object-oriented data model used for query 
processing, mapping into others DML in the 
context of heterogeneous data base access. 
Requirements: Ph.D. in Computer Science. 
Research background in logic programming 
with interpreters using rewriting techniques. 
Proven research background in develop¬ 
ment of user interface on top of UNIX. Pro¬ 
ven research background in combinaterial 
logic programming. $50,500 per year. 40 
hrs/wk. 8:00 - 5:00. Apply by sending 
resume and proof of legal authority to work 
in the U.S. to Colorado Department of 
Labor, Attn: Employment Programs, 600 
Grant St., Suite 900, Denver, CO 80203- 
3528. Refer to Job Offer #C03773943. 


UNIX/C SYSTEMS ENGINEER 

UNIX/C Systems Engineer required. De¬ 
sign, develop and implement custom soft¬ 
ware applications based on analysis of in¬ 
dustry needs. Programming in Fortran, C, 
UNIX shell script, and assembly under DOS, 
UNIX, AIX & TSX platforms. Systems de¬ 
velopment using neural network technol¬ 
ogy, mathematical programming and use 
and modification of algorithms. Work with 
communication protocols. Applicants re¬ 
quired to have a Bachelors Degree in Com¬ 
puters or Engineering with at least 1 year ex¬ 
perience in the job offered. Must have proof 
of legal authority to work in the U.S. An an¬ 
nual salary of $30,000 will be paid for a 
40-hour work week. Interested applicants 
apply at the Texas Employment Commis¬ 
sion, Ft. Worth, TX, or send resume to the 
Texas Employment Commission, Austin, TX 
78778-0001, J.O. #6521592. This adver¬ 
tisement was paid by an equal opportunity 
employment employer. 
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PROJECT SPECIALIST 

Develop software in C, C++, and For¬ 
tran for electronic equipment development 
and data analysis. Develop finite element 
models for new product development and 
product performance. Respond to technical 
requests from engineering, research groups, 
manufacturing, and sales/marketing. Test 
products to determine technical information, 
simulate field conditions. Interface with 
technical service manager to establish, set up 
and/or build testing jigs. Develop theoretical 
models, evaluate data results, and docu¬ 
ment test programs. M.S. in Computer Sci¬ 
ence required. (Will accept completion of all 
coursework.) Must have successfully com¬ 
pleted minimum of one course in each of the 
following: Fortran programming; survey of 
computer languages, advanced program¬ 
ming techniques; advanced human-factors; 
computer architecture; software engineer¬ 
ing; computer organization and design. Must 
have basic knowledge in the area of finite 
element simulations. Hours are 8:00 a.m. to 
5:00 p.m., 40 hours weekly, at an annual 
salary of $33,250. Apply at the Texas Em¬ 
ployment Commission, San Marcos, Texas, 
or send resume to the Texas Employment 
Commission, TEC Building, Austin, Texas, 
78778, J.O. *6687404. Ad Paid by an 
Equal Employment Opportunity Employer. 


SENIOR SOFTWARE DEVELOPER 

Design and develop software applications 
utilizing IBM Cross System Product, SQL- 
DS, Application System, DB2, REXX, Time 
Sharing Option and others. Work on highly 
technical and complex design and coding 
systems, analyze software requirements to 
determine feasibility of design within time 
and cost constraints and formulate and 
design software system using scientific 
analysis and mathematical models to predict 
and measure outcome and consequence of 
design. Develop and direct software systems 
testing procedures, programming and docu¬ 
mentation, in addition to consulting with 
customers concerning maintenance of soft¬ 
ware systems. Direct and coordinate the ac¬ 
tivities of client’s software engineers and the 
implementation of computer software appli¬ 
cation systems, such as Quality Information 
System, Tooling Database System, Decision 
Support Systems, and Executive Informa¬ 
tion Systems, utilizing IBM’s VM and MVS 
operating systems as well as a number of VM 
and MVS products including vision, CSP/ 
AD, CSP/AE, AS, DE2, AND SQL/DS. 
Requires a Bachelor’s Degree in Computer 
Science or Engineering or other appropriate 
discipline or its equivalent and five years ex¬ 
perience in job offered or five years directly 
related experience in analyzing and design¬ 
ing software systems. Background must in¬ 
clude two years experience in Application 
Systems (AS), CSP Operating Systems, and 
Relational Database Technology, such as 
SQL/DS or DB2. 40 hour work week. 
$49,500.00 per year. Apply at the Texas 
Employment Commission, Dallas, Texas or 
send resume to the Texas Employment 
Commission, TEC Building, Austin, Texas 
78778. Job Order *6521659. Ad paid by an 
Equal Employment Opportunity Employer. 


THE UNIVERSITY OF NEVADA, 
LAS VEGAS 

Full-Time Research Position in 
Information Retrieval 

The Information Science Research In¬ 
stitute at the University of Nevada, Las 
Vegas, invites applications for one position 
in Text Retrieval research. This position is a 
soft money/non-tenure track position at the 
Research Assistant or Research Associate 
level. Qualifications include a doctorate in 
Computer Science or related area. Candi¬ 
dates should have demonstrated research 
expertise in Text Retrieval. 

ISRI has acquired and is developing a 
large “Ground-Truth” database for research 
in Optical Character Recognition (OCR) and 
Text Retrieval. The database contains both 
the bit mapped images and the correspond¬ 
ing ASCII output for 90,000 pages of 
English text. Adequate funds for equipment, 
technician support, and graduate student 
support are available. 

The College of Engineering at UNLV cur¬ 
rently operates about 40 Sun SPARCstation 
1 workstations, 16 NeXT workstations, 10 
color DEC VAXstation 3100/s, 2 Silicon 
Graphics IRIS workstations, a Symbolics 
LISP workstation, an Intel Hypercube, and 
several supporting file servers for faculty and 
student use. All equipment runs TCP/IP 
UNIX and is connected to the INTERNET 
through the campus network. Numerous PC 
compatible equipment is also available. 

The College also houses the National 
Supercomputer Center for Energy and the 
Environment which operates a CRAY Y/MP 
2-216 supercomputer. The Y/MP has 5 
gigabytes of high speed disk and a 32 mega¬ 
word SSD. The system is supported by a 
Sun SPARC 4/480 file server with 4 giga¬ 
bytes of disk and a Storage Technology car¬ 
tridge tape system. It is accessed locally in the 
Center via 10 color Sun SPARCstation l’s or 
a Silicon Graphics IRIS workstation. The 
Y/MP is also on the INTERNET. 

Review of applications will begin 7/01/92. 
Position will remain open until filled. Salary 
is commensurate with qualifications and ex¬ 
perience. To apply, send curriculum vita, 
transcripts, and names of at least 3 refer- 

Dr. Kazem Taghva 
University of Nevada, Las Vegas 
Information Science Research Institute 
4505 Maryland Parkway 
Las Vegas, NV 89154 
The University of Nevada, Las Vegas is an 
equal opportunity/affirmative action em¬ 
ployer. UNLV employs only U.S. citizens 
and aliens authorized to work in the U.S. 


INSTRUCTORS WANTED 

Must have; telecommunications back¬ 
ground, 5 years corporate education train¬ 
ing, 7 years software development back¬ 
ground, CASE knowledge Hatley/Pirbhai 
& Yourdon knowledge. Please be advised 
that this position is on an independent con¬ 
tractor basis. 

Send Resumes To: 

Tony Formica 

Kenneth G. Moore and Associates, Inc. 

875 Avenue of the Americas 
New York, NY 10001 


THE UNIVERSITY OF ILLINOIS 
Department of Mechanical and 
Industrial Engineering 

The Knowledge-Based Engineering Sys¬ 
tems Research Laboratory in the Depart¬ 
ment of Mechanical and Industrial Engi¬ 
neering is inviting applications for a Senior 
Software Engineer and a Software Engineer. 
The Senior Software Engineer is expected to 
provide a high level of programming exper¬ 
tise, experience and technical leadership in 
the design, development, evaluation, imple¬ 
mentation, application, and delivery of state- 
of-the-art software systems for practical ap¬ 
plications in sponsoring companies. The 
candidate must have the direct development 
activities, perform knowledge acquisition, 
implement large-scale software, evaluate 
system performance, deliver application 
systems, and interact with industrial spon¬ 
sors. The Software Engineer is primarily 
responsible for the development, evaluation, 
implementation, and delivery of large soft¬ 
ware systems. The main responsibilities in¬ 
clude software project development/testing, 
software quality assurance, knowledge ac¬ 
quisition, technology transfer, and interac¬ 
tion with sponsors. The persons fulfilling 
these positions must be creative and in¬ 
novative self-starts with good technical, 
communication, inter-personal, and leader¬ 
ship skills. The Senior Software Engineer 
must have a M.S. or Ph.D. degree in com¬ 
puter science/engineering, information 
science, or related engineering subjects. A 
minimum of five years work experience in 
applicable areas is required. The Software 
Engineer must have a B.S. or M.S. degree in 
the above areas with minimum of three years 
work experience. Background in design and 
manufacturing automation and experience 
with the automotive industry would be very 
helpful for both positions. Specific software 
knowledge and skills for both positions 
include: (1) object-oriented programming 
techniques with Lisp, C, C + + languages, 
(2) object-oriented database systems and 
database management techniques, (3) de¬ 
sign and implementation of Al-based tools 
and applications, inter-process communica¬ 
tions, and X-window interface on UNIX 
workstations, (4) knowledge acquisition ex¬ 
periences and software engineering method¬ 
ologies. APPOINTMENT: Both positions 
are an academic-professional position on a 
full-time, twelve-month, non-tenure basis. 
STARTING DATE: Anticipated on or short¬ 
ly after July 15, 1992. SALARY: Commen¬ 
surate with qualifications/experience. AP¬ 
PLICATION PROCEDURE: To be assured 
of full consideration, please submit your pro¬ 
fessional resume, and name and addresses 
of three references familiar with your profes¬ 
sional accomplishments by July 1, 1992 to: 
Professor Stephen C-Y. Lu, Director, 
KBESRL, University of Illinois at U-C, 1206 
West Green St., Urbana, IL 61801, U.S.A. 
Tel: (217) 333-6662; Fax: (217) 244-6534. 
Interviews may take place prior to applica¬ 
tion deadline, however, no final decision will 
be made until after the closing date. 

The University of Illinois at U-C is an Affir¬ 
mative Action/Equal Opportunity Employer. 
Applications for the Senior position should 
reference number 3356. Software engineer 
applications should reference 3357. 
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SOFTWARE ENGINEER 


Primarily responsible for full-text proto¬ 
type developing; specifically involved with 
the advanced technical development of our 
TEXT Machine (a full-text searching UTILI¬ 
TY project). Assist in benchmarking and 
testing; development of system documenta¬ 
tion; and advanced software engineering. 
Provides customer support and training. 
Must have knowledge of full-text search and 
retrieval technologies. Must have knowledge 
of C programming and an understanding of 
compiler theory and database theory. Must 
be familiar with UNIX. Must have strong 
communication skills. Master’s Degree in 
Computer Science. No experience required. 
40 hours per week. 8:00 a.m. to 5:00 p.m. 
$37,500.00 per year. Apply to the Texas 
Employment Commission, Austin Texas, or 
send resume to the Texas Employment 
Commission, TEC Building, Austin, Texas 
78778, J.O. No. 6687574. Ad Paid by an 
Equal Employment Opportunity Employer. 


SYSTEMS CONSULTING 

Our client, a premier systems consulting 
organization, seeks permanent professionals 
with 2-10 years proven technical experience 
to join this group which designs and installs 
large-scale leading edge systems. Skill set 
should include; Cobol II, DB2, CICS, UNIX 
and C. Excellent compensation! 

Travel required. Please call Stacey Truglio 
at (212) 736-9429 or send a resume to 
Financial Resources, 2 Penn Plaza, Suite 
1990, New York, NY 10121, Fax: (212) 
643-0409. 


POLYTECHNIC UNIVERSITY 

Applications are invited for the position of 
Head of the Department of Computer Sci¬ 
ence at Polytechnic University. The depart¬ 
ment, which offers BS, MS, and Ph.D. de¬ 
grees, is located in the School of Electrical 
Engineering & Computer Science where it 
benefits from association with Polytechnic’s 
well-established excellence in electrical 
engineering. 

Polytechnic is a private technological urban 
university established in 1854. It is located 
on three campuses in the New York City 
metropolitan area. The main campus is in 
Downtown Brooklyn adjacent to Brooklyn 
Heights, one of New York’s desirable resi¬ 
dential communities. The two suburban 
campuses are located in Farmingdale, Long 
Island, and in Hawthorne, Westchester 
County. The department’s growth mode is 
evidenced by faculty openings, increased ex¬ 
ternal research funding, and its move into a 
new university building in Brooklyn that is 
part of the 16-acre MetroTech development 
of buildings for academic, research, and 
commercial activities. The university has an 
enrollment of approximately 4,500 stu¬ 
dents. As a result of the university’s favorable 
location, faculty and students enjoy close in¬ 
teractions with major companies that manu¬ 
facture and use electronic computers. 

The Department of Computer Science 
currently has 18 tenure-track faculty mem¬ 
bers. Its undergraduate program is ac¬ 
credited by CSAB, and in 1991 it awarded 
118 MS degrees and 7 Ph.D. degrees. Areas 
of active research include parallel, distributed 
and randomized algorithms, computational 
biology, parallel and distributed computing, 
computational geometry, software reliability 


and testing, computer architecture, large 
distributed data bases, network manage¬ 
ment, and image analysis and understand¬ 
ing. Faculty and students have access to a 
wide variety of mainframe and work station 
computers, which are fully networked. 

The applicant should have a Ph.D. degree 
and an outstanding record of research and 
teaching in Computer Science. Qualified ap¬ 
plicants should send their curriculum vitae 
and names of at least three references to the 
Chairman of the Search Committee, Profes¬ 
sor Richard Mandelbaum, Center for Ad¬ 
vanced Technology in Telecommunications, 
Polytechnic University, Six MetroTech 
Center, Brooklyn, NY 11201. Polytechnic is 
an Equal Opportunity Employer. M/F/V/H. 
Questions can be directed to: lshaw@tasha. 
poly.edu. 


COMPUTER SYSTEMS SPECIALIST 

Computer Systems Specialist for compu¬ 
ter consulting firm. Duties include planning, 
directing and coordinating activities of com¬ 
puter professionals in Tech Services Dept. 
Will consult with management to define pro¬ 
ject priorities, project development and 
evaluation. Must have BS in business or 
math and five years experience as Sr. Sys¬ 
tems Analyst or EDP Project Manager w/ex¬ 
perience in OPNS and maintenance industry 
applications. Salary $44K/yr. Job site and 
interview, Evergreen, Colorado. Apply by 
resume only to: Colorado Dept, of Labor & 
Employment, 600 Grant St., # 900, Denver, 
CO 80203-3528. Attn: Employment Pro¬ 
gram , Job Order * *003773926 no later than 
7/1/92. 


CALL FOR PAPERS 

International Workshop on Modeling, Analysis and Simulation of 
Computer and Telecommunication Systems 

MASCOTS'93 

Part o( the 1993 SCS Western Multiconference on Computer Simulation 

(ACM. IEEECS. IFIPWG. ORSA cooperation/sponsorships are pending) 
January 17-20.1993. Hyatt Hotel. La Jolla. San Diego. California, USA 


Topics of interest include^ but are not lin 
Systems and Techniques such as: 

• Parallel and Distributed Systems 

• High-Speed Computer Networks 

• VLSI and Scalable Systems 

• Applications: DSP, AH Expert Sys- 

Robotics and Control etc. 

• Analytic (Performance, Reliability 

and Performability) Modeling 

• Discrete Simulation Techniques 

• Numeric Simulation and Visualiza¬ 

tion Techniques 


mited to Modeling/Analysis/Simulation of 


• Artificial Neural Networks 

• Large, Distributed, (Incomplete) 

Data-base Systems 

• Fault Tolerant and Real-Time Sys- 

• Specification and Validation Methods 

as in Network Protocols, Logic 

• Intelligent Simulation Techniques 

with Knowledge as the key 


General Chair 
Herb Schwetman 
MCC 

3500 West Baleones Center Dr. 
Austin. TX 78759 USA 

Phone: (1) 512-338-3428 
Fax: (1) 512-338-3885 
Email: hds@mcc.com 


Program Committee Chair 
Jean Walrand 

Dept, of Electrical Engineering 
and Computer Sciences 
University of California 
Berkeley. CA 94720 USA 
Phone: (1)510-642-1529 
Fax: (1) 510-643-8426 


July 15,1992 Four copies of submission due 

Schedule : Sept. 15,1992 Notification of acceptance 

Oct. 15,1992 Deadline for camera-ready copy 

Proceedings are published by the SCS. A selected set of papers will be published 
by Kluwer Academic Publishers. For more information contact Kallol Bagchi 
(kkb@iesd.auc.dk) or Patrick Dowd (dowd@eng.buffalo.edu). 


BIG TESTER CAPABILITY 



SMALL TESTER PRICE 


Need a powerful solution for device and functional 
board testing? The ETS200 Benchtop. < $300/pin. 

* Windows 3.0 Compatible 

* Pin per pin programmability 

* Expandable to 192 pins 

CALL 1-800-HILEVEL TODAY 

L Q~ 77 / A/C. 
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CALL FOR PAPERS 


HPN 92, Fourth Conf. on High-Perfor¬ 
mance Networking: Dec. 16-18,1992, 

Liege, Belgium. Sponsor: Int’l Federation 
for Information Processing. Submit four 
copies by June 26,1992, and camera-ready 
version by Nov. 20,1992, to Andre Dan- 
thine, Univ. de Liege, Inst. d’Electricitd 
Montefiore, B-4000, Liege, Belgium, 
phone 32 (41) 56-26-91, fax 32 (41) 56-29- 
89, e-mail danthine@vml.ulg.ac.be. 

IJCNN 92, Int’l Joint Conf. on Neural Net¬ 
works: Nov. 3-6,1992, Beijing, China. Co¬ 
sponsors: IEEE Neural Networks Council 
et al. Submit six-page final paper by June 
30, 1992, to Harold Szu, 9402 Wildoak Dr., 
Bethesda, MD 20814, phone (301) 394- 
3097, fax (301) 394-3923, e-mail btelfe® 
ulysses.nswc.navy.mil. 

J. of Systems and Software plans a special 
issue in March 1993 on applying validation. 


verification, and validation techniques to 
industrial software systems. Publisher: 
North-Holland. Submit five copies of full 
manuscript by June 30,1992, to James M. 
Bieman or Pradip K. Srimani, Computer 
Science Dept., Colorado State Univ., Ft. 
Collins, CO 80523, phone (303) 491-7096 
or 7097. fax (303) 491-6639, e-mail 
bieman@cs.colostate.edu or srimani@cs. 
colostate.edu. 

Int'l Conf. on Signals, Data, and Systems: 
Modeling, Simulation, and Control: Oct. 5- 
7, 1992, Hefei, China. Cosponsors: Int'l 
Assoc, for the Advancement of Modeling 
and Simulation Technology in Enterprises 
et al. Submit one-page summary by June 
30, 1992, to G. Mesnard, AMSE, 16 Av. 
Grange Blanche, 69160 Tassin-la-Demi- 
Lune, France, fax (33) 78-34-54-17; or 
(submittals from China) Bao Yuanlu, Au¬ 
tomation Dept., Univ. of Science and Tech. 


of China, Hefei, Anhui, 230026, fax (0551) 

331-760. 


ICDE 93, Ninth Int’l Conf. on Data 
'5*5' Eng.: Apr. 19-23,1993, Vienna. Sub¬ 
mit five copies of complete paper (approxi¬ 
mately 5,000 words) by July 1,1992, and 
camera-ready copy by Jan. 1,1993, to 
Erich J. Neuhold, GMD-IPSI, Dolivo- 
strasse 15, D-6100 Darmstadt, Germany, 
phone 49 (6151) 869-803, fax 49 (6151) 
869-818, e-mail icde@darmstadt.gmd.de. 

Conf. on Simulation Applications in 

Business Management and MIS: Jan. 
17-20,1993, La Jolla, Calif. Sponsor: Soc. 
for Computer Simulation. Submit abstract 
and regular paper (about 12 double-spaced 
pages) or abstract and short paper (about 6 
double-spaced pages) by July 1, 1992, and 
camera-ready copy by Sept. 30,1992, to 
Stuart Monroe, Computer Information 


Call for articles and referees for IEEE Computer Society 


The following IEEE magazines seek articles for inclusion in future issues: 


IEEE Computer Graphics & Appli¬ 
cations, which serves users and de¬ 
signers of graphics hardware, soft¬ 
ware, and systems, seeks submittals 
on various subjects. The magazine in¬ 
vites papers presenting theories and/ 
or related practices, along with those 
reporting applications or discussing al¬ 
gorithms. The editors also welcome tu¬ 
torials, surveys, and special topics. 
Sample subjects include scientific vi¬ 
sualization, display technology, high- 
performance graphics engines, CAD/ 
CAM/CAE, computer imaging, geomet¬ 
ric modeling, business graphics, hu¬ 
man factors, distributed graphics tech¬ 
niques and systems, standards, 
rendering algorithms, and computer 
animation and simulation. To submit 
papers, write to the editor-in-chief, Pe¬ 
ter R. Wilson, Design Research Cen¬ 
ter, Cll 7015, Rensselaer Polytechnic 
Inst., Troy, NY 12108. To obtain cop¬ 
ies of the guidelines for authors, call 
Karen Potes in the Publications Office 
at (714) 821-8380. 

IEEE Design & Test of Computers 

seeks general-interest papers (20 dou¬ 
ble-spaced pages, including figures) 
for its 1993 issues. Suggested topics 
include reviews of tools, design experi¬ 
ences, and design methodologies; use 
of CAE/CAD tools in the design pro¬ 
cess; test strategies and economics; 


DFT vs. cost; D/A test; system-level 
trade-offs; rapid prototyping; packaging; 
manufacturing databases; and special- 
purpose tools. Submit a 300-word ab¬ 
stract, keywords, and your mail/e-mail ad¬ 
dresses, along with six copies of the 
paper, to Manuel d’Abreu, GE R&D, 1 
River Rd., PO Box 8, KW-C308, Sche¬ 
nectady, NY 12301, phone (518) 387- 
7097, fax (518) 387-7332, dabreu@crd. 
ge.com. 

IEEE Expert invites articles on all as¬ 
pects of intelligent systems, including ex¬ 
pert systems, embedded intelligence, ro¬ 
botics, neural networks, fuzzy systems, 
natural language, automated manufactur¬ 
ing, learning, and related social, manage¬ 
ment, and legal issues. The bimonthly 
magazine focuses on current practices 
and experiences in intelligent systems 
and promising new ideas that are ready 
for application to real-world problems. All 
manuscripts must be original; articles 
published in other magazines or journals 
will not be considered. Send six double¬ 
spaced copies and a cover letter to B. 
Chandrasekran, Editor-in-Chief, IEEE Ex¬ 
pert, c/o Ohio State Univ., Computer and 
Information Science Dept., Rm. 217, Bolz 
Hall, 2036 Neil Ave., Columbus, OH 
43210-1277. 

IEEE Micro invites authors to submit 
original papers for the April 1993 joint is¬ 


magazines 


sue with Computer on multichip mod¬ 
ules (Micro will address packaging 
and interconnections) by Aug. 1, 

1992. Also welcome at any time are 
general-interest submissions. Sug¬ 
gested topics include multiprocess¬ 
ing, optical and biological computing, 
microcomputing to aid the handi¬ 
capped, systems design, DSP-based 
tools, solid-state memory, and fuzzy- 
logic chips. Submit six copies of each 
paper to Dante Del Corso, Diparti- 
mento di Elettronica, Politecnico di 
Torino, C. so duca degli Abruzzi, 24, 
10129 Torino, Italy, e-mail 
delcorso@polito.it. For author guide¬ 
lines, dial (714) 821-8380. 

IEEE Software seeks articles for 
inclusion in a special issue on soft¬ 
ware synthesis to appear in May 

1993. Reusability using software syn¬ 
thesis techniques, domain-specific 
software synthesis, and handling of 
cost trade-offs in software synthesis 
are examples of the topics of interest. 
Eight copies of previously unpub¬ 
lished papers should be sent by Sept. 
1,1992, and final versions are due by 
Jan. 15,1993. Make submittals to 
Dorothy Setliff, 341 Benedum Hall, 
Electrical Eng. Dept., Univ. of Pitts¬ 
burgh, Pittsburgh, PA 15261, phone 
(412) 624-9695, fax (412) 624-1108, 
e-mail setliff@es.pitt.edu. 
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Systems and Management Science, Metro¬ 
politan State College of Denver, Denver, 
CO 80217-3362, phone (303) 556-8506, fax 
(303) 556-4429, e-mail monroe@zeno.msc. 
colorado.edu. 


CTw ISADS 93,1993 Int’l Symp. on Au- 
(omniums Decentralized Systems: 

Mar. 30-Apr. 1, 1993. Kawasaki, Japan. 
Cosponsors: Information Processing Soc. 
of Japan et al. Submit eight copies of full 
paper by July 1, 1992, and final version by 
Dec. 29, 1992, to Domenico Ferrari, Elec¬ 
trical Eng. and Computer Sciences Dept., 
Univ. of California, Berkeley. CA 94720. 
For program information, fax to (510) 642- 
5775, e-mail isads@tenet.berkeley.edu. 


ISIT 93,1993 IEEE Int’l Symp. on Infor¬ 
mation Theory: Jan. 17-22, 1993, San An¬ 
tonio, Texas. Sponsor: IEEE Information 
Theory Soc. Submit short paper (500-word 
summary and 180-word abstract) by July 1, 
1992, to Richard E. Blahut, Mail Drop 
0600, IBM, Route 17C, Owego, NY 13827, 
phone (607) 751-2217. 


Third Int’l Symp. on Integrated Network 
Management: Apr. 18-23,1993, San Fran¬ 
cisco. Cosponsors: Int’l Federation for In¬ 
formation Processing, IEEE Committee on 
Network Operations and Management. 
Submit seven copies of paper by July 1, 
1992, and camera-ready version by Dec. X, 

1992, to Yechiam Yemini, Columbia Univ., 
450 Computer Science Bldg., New York, 
NY 10027; or Heinz-Gerd Hegering, Univ. 
of Munich, Inst, fuer Informatik-LRZ, 
Barer Strasse 21, D-8000 Muenchen 2, 
Germany. 

1993 Advanced Tech. Forum: Apr. 19-21, 

1993, Cleveland. Cosponsors: Inst, of In¬ 
ternal Auditors Research Foundation et al. 
Submit outline and complete summary by 
July 1,1992. and final paper by Nov. 1, 
1992, to A. Frank Allen, IIA, 249 Maitland 
Ave., Altamonte Springs, FL 32701-4201. 

Fourth NASA Symp. on VLSI Design: 

Oct. 29-30,1992, Coeur d’Alene, Idaho. 
Cosponsors: Spokane, Washington, IEEE 
Section, Univ. of Idaho NASA Space Eng. 
Research Center. Submit four Copies of 
500-word summary and 50-word abstract 
by July 1,1992, and final version by Sept. 

1,1992, to Sterling Whitaker, NASA 
SERC, Univ. of Idaho, Moscow, ID 83843, 
phone (208) 885-6500, fax (208) 885-6840, 
e-mail swhitaker@grieg.mrc.uidaho.edu. 

Int’l J. in Computer Simulation seeks pa¬ 
pers for a special issue on intelligent simu¬ 
lation for high-autonomy systems. Publish¬ 
er: Ablex. Submit five copies of full 
manuscript by July 10,1992. to Albert Y. 
Zomaya, Electrical and Electronic Eng. 
Dept., Univ. of Western Australia, Ned- 
lands, Perth, Western Australia 6009, 
phone 61 (9) 380-3875, fax 61 (9) 380-1065, 
e-mail zomaya@swanee.ee,uwa.oz.au. 

30th Allerton Conf. on Comm., Control, 
and Computing: Sept. 30-Oct. 2,1992, 
Monticello, Ill. Sponsor: Univ. of Illinois at 
Urbana-Champaign. For regular paper, 


submit a title and 5- to 10-page extended 
abstract; for short papers, submit a title 
and 1,000-word summary. Submit materials 
to Allerton Conf., Univ. of Illinois, Coordi¬ 
nated Science Lab, 1101 W. Springfield 
Ave., Urbana, IL 61801 by July 13,1992. 
Contact Paul Van Dooren, phone (217) 
333-0656, e-mail vdooren@uicsI.csl.uiuc. 
edu; or Mark Spong, phone (217) 333-4281, 
e-mail spong@lagrange.csl.uiuc.edu. 

® IEEE Infocom 93, 12th Conf. on 
Computer Comm.: Mar. 28-Apr. 1, 
1993, San Francisco. Cosponsor: IEEE 
Comm. Soc. Submit five double-spaced 
copies of manuscript by July 15,1992, and 
camera-ready copy by Dec. 7,1992, to 
Kenneth Vastola, ECSE Dept., Rensselaer 
Polytechnic Inst., Troy, NY 12180-3590, 
phone (518) 276-6074, e-mail infocom@ 
ecse.rpi.edu. 


RIDE-IMS 93, Third Int’l Workshop 
NSZ on Research Issues in Data Eng. — 
Interoperability in Multidatabase Systems: 

Apr. 18-20,1993, Vienna. Cosponsor: Aus¬ 
trian Computer Soc. Submit six copies of 
paper (20-page maximum) by July 15, 

1992, and camera-ready version by Jan. 1, 

1993, to Amit Sheth, Bellcore, RRC 1J- 
210, 444 Hoes Lane, Piscataway, NJ 08854- 
4182, phone (908) 699-3300, fax (908) 336- 
2969, e-mail amit@ctt.bellcore.com (in the 
Americas, Asia, and Australia); or Hans-J. 
Schek, Computer Science Dept., Swiss 
Federal Inst, of Tech-, ETH Zentrum, CH- 
8092 Zurich, Switzerland, phone 41 (1) 
254-7240, fax 41 (1) 262-3973, e-mail 
schek@inf.ethz.ch (in Europe and Africa). 


1084, phone (512) 471-4085, fax (512) 471- 
5807, e-mail clwu@emx.utexas.edu. 

First Sharjah Conf. on Geographic Infor¬ 
mation Systems and Applications: Feb. 8- 
10,1993, Sharjah, United Arab Emirates. 
Sponsor: Sharjah Municipality. Submit 
three copies of paper outline (about 200 
words) by July 15,1992. and three camera- 
ready copies of the paper by Nov. 20,1992, 
to Obeid Ahmed, Sharjah Municipality, In¬ 
formation Tech. Center, PO Box 22, Shar¬ 
jah, UAE, phone (9716) 541-333, fax 
(9716) 546-455. 

12th IEEE Int’l Phoenix Conf. on 

Computers and Comm.: Mar. 24-26, 
1993, Scottsdale, Ariz. Submit five copies 
of complete paper (5,000-word maximum) 
by July 17,1992, and camera-ready version 
by Nov. 30,1992, to Robert Meitz, Arizona 
State Univ., Aeronautical Tech. Dept., 
Tempe, AZ 85287-6406, phone (602) 965- 
7775, fax (602) 965-5089, e-mail idrom@ 
asuvm.inre.asu.edu. 

ICSEE 93, Int’l Conf. on Simulation 
n!?' in Eng. Education: Jan. 17-20,1993, 
La Jolla, Calif. Cosponsors: Soc. for Com¬ 
puter Simulation et al. Submit four copies 
of regular paper (about 12 double-spaced 
pages) or short paper (about 6 double¬ 
spaced pages) by July 31,1992, and cam¬ 
era-ready copy by Sept. 30, 1992, to 
Charles Knadler. IBM, Advanced Automa¬ 
tion Systems, 9201 Corporate Blvd., Rock¬ 
ville, MD 20850, phone (301) 640-3124, fax 
(301) 640-2136, e-mail knadlerc@wmavm7. 


Mascots 93, Int’l Workshop on Mod¬ 
eling, Analysis, and Simulation of 
Computer and Telecommunication Sys¬ 
tems: Jan. 17-20,1993, La Jolla, Calif. 
Sponsors: Soc. for Computer Simulation 
et al. Submit four copies of paper (10 dou¬ 
ble-spaced pages) by July 15,1992, and 
camera-ready copy by Oct. 15,1992, to 
Jean Walrand, Electrical Eng. and Com¬ 
puter Sciences Dept., 267M Cory Hall, 
Univ. of California, Berkeley, CA 94720, 
phone (510) 642-1529, fax (510) 643-8426, 
e-mail wlr@diva.berkeley.edu. 

ICS 92, Int’l Computer Symp.: Dec. 13-15. 
1992, Taichung, Taiwan, Republic of Chi¬ 
na. Cosponsors: IEEE Taipei et al. Submit 
four copies of paper (maximum of 20 dou¬ 
ble-spaced pages) and abstract by July 15, 
1992. to An-Chi Liu, Information Eng. 
Dept., Feng Chia Univ., Taichung, Taiwan, 
ROC, phone 886 (4) 252-2250 ext. 3700, 
e-mail fcut003@twnmoel0.bitnet (Far East 
submittals); or Ben W. Wah, Coordinated 
Science Lab, Univ. of Illinois, 1101 W. 
Springfield Ave,, Urbana, IL 61801, phone 
(217) 244-7175, e-mail wah@manip.csl. 
uiuc.edu (all other regions). 

ICPADS 92,1992 Int’l Conf. on Parallel 
and Distributed Systems: Dec. 16-18,1992, 
Hsinchu, Taiwan. Sponsor: Nat’l Tsing 
Hua Univ. Submit five copies of full paper 
(maximum of 20 double-spaced pages) by 
July 15,1992, to Chuan-lin Wu, ECE 
Dept., Univ. of Texas, Austin, TX 78712- 


12th World Congress: July 18-23,1993, 
Sydney, Australia. Sponsor: Int’l Federa¬ 
tion of Automatic Control. Submit five 
copies of paper by July 31,1992, and final 
paper by Feb. 28,1993, to IFAC Secretari¬ 
at, Electrical and Computer Eng. Dept., 
Univ. of Newcastle, University Dr., Cal¬ 
laghan, NSW 2308, Australia, phone 61 
(49) 601-712, fax 61 (49) 216-025, e-mail 
eegcg@cc.newcastle.edu.au. 

ICBGM 93,1993 Int’l Conf. on Bond 
Graph Modeling and Simulation: Jan. 17- 
20,1993, San Diego, Calif. Sponsor: Soc. 
for Computer Simulation. Submit short pa¬ 
per (about six pages) or long paper (about 
12 pages) by July 31,1992, and camera- 
ready version by Sept. 30,1992, to Jose J. 
Granda, Mechanical Eng. Dept., California 
State Univ. at Sacramento, Sacramento, 
CA 95819, phone (916) 278-5711, fax (916) 
278-5949, e-mail grandajj@ecs.csus.edu; or 
Francois E. Cellier, Electrical and Com¬ 
puter Eng. Dept., Univ. of Arizona, Tuc¬ 
son, AZ 85721, phone (602) 621-2692, fax 
(602) 621-8076, e-mail cellier@ece.arizona. 
edu. 

1993 Conf. on Discrete and Combined 
Simulation: Jan. 17-20,1993, La Jolla, 

Calif. Sponsor: Soc. for Computer Simula¬ 
tion. Submit four copies of regular paper 
(about 12 double-spaced pages) or short 
paper (about 6 double-spaced pages) by 
July 31, 1992, and camera-ready copy by 
Sept. 30,1992, to Stanislaw Raczynski, 
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Univ. Panamericana, Esoula de Ingenieria, 
Augusto Rodin 498,03910 Mexico D.F., 
phone (402) 472-1977, fax (402) 563-8543; 
or SCS, 4838 Ronson Ct., Suite L, San Di¬ 
ego, CA 92111, phone (619) 277-3888, fax 
(619) 277-3930, e-mail mcleod@scsc.bitnet. 

1993 Conf. on Simulation in the Health 

Sciences and Services: Jan. 17-20,1993, La 
Jolla, Calif. Sponsor: Soc. for Computer 
Simulation. Submit four copies of regular 
paper (about 12 double-spaced pages) or 
short paper by July 31,1992, and camera- 
ready copy by Sept. 30,1992, to Meyer 
Katzper, 2 Locks Pond Ct., Rockville, MD 
20854, phone (301) 443-0316, fax (301) 
443-9283, e-mail $mlk@pccjes2.bitnet. 

1992 Int'l Bankai Workshop on Adaptive 
Intelligent Systems: Oct. 12-14,1992, Brus¬ 
sels. Sponsor: Soc. for Worldwide Inter¬ 
bank Financial Telecommunications. Sub¬ 
mit abstract by Aug. 1,1992, to Brigitte 
Diraison, AI Lab, SWIFT s.c., 1 Av. 

Adele, 1310 La Hulpe, Belgium, phone 32 
(2) 655-3153, fax 32 (2) 655-3785. 

Fifth Workshop on Software Reuse: Oct. 
26-29,1992, Palo Alto, Calif. Submit posi¬ 
tion paper in required format by Aug. 1, 
1992. For submission guidelines, contact 
Martin Griss, Hewlett-Packard Labs, 1501 
Page Mill Rd„ Palo Alto, CA 94304-1126, 
phone (415) 857-8715, fax (415) 857-8526, 
e-mail griss@hpl.hp.com. 

ISUMA 93, Second Int’l Symp. on 
Uncertainty Modeling and Analysis: 

Apr. 25-28,1993, College Park, Md. Co¬ 
sponsors: Univ. of Maryland et al. Submit 
four copies of 250-word abstract by Aug. 1, 
1992, and final paper by Jan. 15,1993, to 
Bilal M. Ayyub, Civil Eng. Dept., Univ. of 
Maryland, College Park, MD 20742, phone 
(301) 405-1956, fax (301) 314-9320, e-mail 
bal5@umail.umd.edu. 


Working Conf. on Architectures and Com¬ 
pilation Techniques for Fine- and Medium- 
Grain Parallelism: Jan. 20-22,1993, Orlan¬ 
do, Fla. Sponsor: Int’l Federation for In¬ 
formation Processing. Submit four copies 
of 20-page manuscript by Aug. 14,1992, 
and camera-ready paper by Oct. 30,1992, 
to Jean-Luc Gaudiot, Univ. of Southern 
California, Electrical Eng.-Systems Dept., 
Los Angeles, CA 90089-2563, phone (213) 
740-4484, fax (213) 740-4449, e-mail 
gaudiot@usc.edu. 


IEEE Workshop on Imprecise and 
Approximate Computation: Dec. 1, 
1992, Phoenix, Ariz. Cosponsors: IEEE 
Computer Soc. Technical Committee on 
Real-Time Systems et al. Submit six copies 
of position paper (up to five pages) by 
Aug. 15,1992, and camera-ready version 
by Nov. 6,1992, to Wei Zhao, Computer 
Science Dept., Texas A&M Univ., College 
Station, TX 77843-3112, phone (409) 845- 
5098, fax (409) 847-8578, e-mail zhao@cs. 
tamu.edu. 


Third Int’l Workshop on Network and Op¬ 
erating System Support for Digital Audio 
and Video: Nov. 12-13,1992, La Jolla, 


Calif. Sponsor: IEEE Comm. Soc. Submit 
500- to 2,000-word position paper or ex¬ 
tended abstract by Aug. 15,1992, by e-mail 
to av-workshop@cs.ucsd.edu. Submit final 
paper by Oct. 15,1992, to P. Venkat Ran- 
gan, Multimedia Lab, Computer Science 
Dept., Univ. of California at San Diego, La 
Jolla, CA 92093-0114, phone (619) 534- 
5419, fax (619) 534-7029, e-mail venkat@cs. 
ucsd.edu. 


Int’l Conf. on Signals, Data, and Systems: 
Methodologies and Applications: Dec. 7-9, 
1992, Calcutta, India. Sponsor: Int’l Assoc, 
for the Advancement of Modeling and 
Simulation Technology in Enterprises et 
al. Submit two copies of one-page summa¬ 
ry by Aug. 20,1992, to AMSE, 16 Av. 
Grange Blanche, 69160 Tassin-la-Demi- 
Lune, France, fax (33) 78-34-54-17. 


(iji) Solid Modeling 93, Second ACM/ 
IEEE Symp. on Solid Modeling and 
Applications: May 19-21,1993, Montreal, 
Canada. Submit abstract (150-300 words) 
by Sept. 1,1992, full paper (6,000-word 
maximum) by Oct. 15,1992, and camera- 
ready version by Feb. 7,1993, to Mary 
Johnson, Design Research Center, CII 
7015, Rensselaer Polytechnic Inst., Troy, 
NY 12180-3590, phone (518) 276-6751, fax 
(518) 276-2702, e-mail mjohnson@rdrc.rpi. 
edu. 


EDAC 93, Fourth European Design 
Automation Conf., and EuroASIC 
93, European Event in ASIC Design: Feb. 
22-25,1993, Paris. Submit paper by Sept. 2, 
1992, and final version of manuscript by 
Nov. 27,1992, to EDAC-EuroASIC 93, 
CEP Consultants, 26-28 Albany St., Edin¬ 
burgh, EH1 3QH, Scotland, phone 44 (31) 
557-2478, fax 44 (31) 557-5749. 


Int’l Multiconference on Application of 
Signals, Data, and Systems Methodologies 
to Eng. Problems: Dec. 28-30,1992, Alex¬ 
andria, Egypt. Sponsor: Int’l Assoc, for the 
Advancement of Modeling and Simulation 


Technology in Enterprises et al. Submit 
two copies of one-page summary by Sept. 

10.1992, to AMSE, 16 Av. Grange 
Blanche, 69160 Tassin-la-Demi-Lune, 
France, fax (33) 78-34-54-17. 

ETC 93, European Test Conf.: Apr. 

19-24,1993, Rotterdam, The Nether¬ 
lands. Submit four copies of paper by Sept. 

11.1992, and camera-ready manuscript by 
Jan. 22,1993, to Jacques Kevers, ETC 93 
Secretariat, IEEE Computer Soc., 13 Ave¬ 
nue de l’Aquilon, B-1200 Brussels, Bel¬ 
gium, phone 32 (2) 770-22-42 or 21-98, fax 
32 (2) 770-85-05. 

Third Int’l Symp. on Database Sys- 

terns for Advanced Applications: 

Apr. 6-8,1993, Deajon, Korea. Sponsors: 
Korean Information Science Soc., Informa¬ 
tion Processing Soc. of Japan. Submit six 
copies of full paper (5,000-word maximum) 
by Sept. 12,1992, to SongChun Moon, 
KAIST, 207-43 Cheongryang, Dongdae- 
mun, Seoul 130-012, Korea, fax 82 (2) 960- 
6743, e-mail moon@dbsun2.kaist.ac.kr. 

26th Simulation Symp.: Mar. 29-Apr. 
VEX 1,1993, Washington, D.C. Sponsor: 
Soc. for Computer Simulation. Submit four 
copies of complete paper (10 to 20 double¬ 
spaced pages) by Sept. 15,1992, to John A. 
Miller, Computer Science Dept., 415 Grad¬ 
uate Studies Research Center, Univ. of 
Georgia, Athens, GA 30602, phone (706) 
or (404) 542-3440, e-mail jam@pollux.cs. 
uga.edu. 

IPPS 93, Seventh Int'l Parallel Pro- 

cessing Symp.: Apr. 13-16,1993, 
Newport Beach, Calif. Cosponsor: ACM 
SIGArch. Submit five copies of complete 
manuscript (15 single-spaced pages maxi¬ 
mum) by Sept. 30,1992, and camera-ready 
paper by Jan. 29,1993, to Viktor K. 
Prasanna, EE Systems Dept., EEB 244, 
Univ. of Southern California, Los Angeles, 
CA 90089-2562, fax (213) 740-4449, e-mail 
ipps93@halcyon.usc.edu. 
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listed. The free notices are published in chronological order and as space permits. 

For inclusion in the Call for Papers section, please submit the name of the 
event, date(s), location, sponsor(s), deadline for submittals, phone and fax num¬ 
bers, and — if applicable —the electronic address of the person to whom papers 
should be sent. 

For the Calendar section, please provide the event name, date(s), location, 
sponsor(s), phone and fax numbers, and the electronic address of the person to 
contact for complete information. 

Submitted information should arrive at Computer at least five weeks before the 
month of publication (i.e., for the August 1992 issue, send information for re¬ 
ceipt by June 19, 1991) to Chuck Governale, Calendar Dept., Computer, PO Box 
3014, Los Alamitos, CA 90720-1264, fax (714) 821-4010, e-mail c.governale® 
compmail.com. 


June 1992 

Workshop on Neural Networks: From Bi¬ 
ology to High-Energy Physics, June 18-26, 

Elba Island, Italy. Sponsors: Italian Nat’l 
Health Inst., Italian Nat’l Inst, for Nuclear 
Research. Contact Paola Di Ciaccio, fax 39 
(6) 446-2872, e-mail paolad@irmiss.bitnet 
or paolad@sanita.infn.it. 

15th lnt’1 Conf. on Research and Develop¬ 
ment in Information Retrieval, June 21-24, 

Copenhagen, Denmark. Sponsors: Royal 
School of Librarianship, ACM. Contact 
Peter Ingwersen, Danmarks Biblioteks- 
skole, RSL, 6 Birketinget, DK-2300, 
Copenhagen S, Denmark. 


Ithaca, NY 14853, phone (607) 255-9204, 
fax (607) 255-4428. 

Seventh IEEE Conf. on Structure in 
Complexity Theory, June 22-25, Bos¬ 
ton. Sponsor: IEEE Computer Soc. Tech¬ 
nical Committee for Math. Foundations of 
Computing. Contact J. Royer, School of 
Computer and Information Science, Syra¬ 
cuse Univ., Syracuse, NY 13244, fax (315) 
443-1954, e-mail royer@top.cis.syr.edu. 

1992 Conf. of the Assoc, for Information 
and Image Management, June 22-25, Ana¬ 
heim, Calif. Contact AIIM, Education 
Dept., 1100 Wayne Ave., Suite 1100, Silver 
Spring, MD 20910, phone (301) 587-8202, 
fax (301) 587-2711. 


LFP 92, Conf. on Lisp and Functional Pro¬ 
gramming, June 22-24, San Francisco. 
Sponsor: ACM. Contact Jon White, Lucid 
Inc., 707 Laurel St., Menlo Park, CA 
94025, phone (415) 329-8400, e-mail jonl@ 
lucid.com. 

TPCD 92, InlT Conf. on Theorem Provers 
in Circuit Design, June 22-24, Nijmegen, 
The Netherlands. Sponsors: Int’l Federa¬ 
tion for Information Processing, Dutch 
Nat’l Facility for Informatics. Contact Har¬ 
riet Reker, TPCD 92, Univ. of Nijmegen, 
Computer and Comm. Systems Group, PO 
Box 9010, 6500 GL Nijmegen, The Nether¬ 
lands, e-mail germaine@cs.kun.nl. 

LICS, Seventh IEEE Symp. on Logic 

in Computer Science, June 22-25, 

Santa Cruz, Calif. Sponsor: IEEE Comput¬ 
er Soc. Technical Committee on Mathe¬ 
matical Foundations of Computing. Con¬ 
tact Robert L. Constable, Computer 
Science Dept., Cornell Univ., 4149 Upson, 


Second Int'l Conf. on Artificial Intelli¬ 
gence in Design, June 22-25, Pittsburgh. 
Cosponsors: Key Centre of Design Quality 
et al. Contact John Gero or Fay Sudweeks, 
Key Centre of Design Quality, Univ. of 
Sydney, NSW 2006, Australia, phone 61 
(2) 692-2328, fax 61 (2) 692-3031, e-mail 
john@archsci.arch.su.oz.au or fay@archsci. 


12th Int'l Symp. on Protocol Specification, 
Testing, and Verification, June 22-25, Or¬ 
lando, Fla. Cosponsors: Nat’l Inst, for Sci¬ 
ence and Tech., AT&T Bell Labs. Contact 
M. Umit Uyar, AT&T Bell Labs, Rm. 
3D501A, Crawfords Corner Rd., Holmdel, 
NJ 07733, phone (908) 949-0350, fax (908) 
949-1652. 


|CT»I CGI 92,10th Int’l Conf. on Comput- 
er Graphics, June 22-26, Tokyo. Co¬ 
sponsors: Computer Graphics Soc. et al. 
Contact R.A. Earnshaw, Computer Graph¬ 
ics, Univ. of Leeds, Leeds LS2 9JT, En¬ 


gland, phone 44 (532) 335-414, fax 44 (532) 
336-017; or REN Associates, Second Nichi- 
ka Bldg., 2-12-14 Hamamatsucho, Minato- 
ku, Tokyo 105, Japan, phone 81 (3) 3433- 
2543, fax 81 (3) 3433-2544, e-mail cgi92@ 
nttarm.ntt.jp. 

(fft) RSP, Third Int’l Workshop on Rapid 
NS? System Prototyping, June 23-25, Re¬ 
search Triangle Park, N.C. Cosponsors: 
IEEE Computer Soc. Technical Commit¬ 
tees on Design Automation, Simulation, 
and Test Tech. Contact Nick Kanopoulos, 
Center for Systems Eng., Research Trian¬ 
gle Inst., 3040 Cornwallis Rd., Research 
Triangle Park, NC 27709, phone (919) 541- 
7341, fax (919) 541-6515, e-mail rsp@rti.rti. 
org. 

Optical Amplifiers and Their Applications, 
June 24-26, Santa Fe, N.M. Sponsor: IEEE 
Lasers and Electro-Optics Soc. Contact 
IEEE LEOS, 445 Hoes Lane, PO Box 
1331, Piscataway, NJ 08855-1331, phone 
(908) 562-3893, fax (908) 562-1571. 

10th Software Reliability Symp., 

June 25-26, Denver. Sponsor: IEEE 
Reliability Soc. Denver Chapter. Contact 
Rich Karcich, Storage Tech. Corp., 2270 S. 
88th St., MS 2286, Louisville, CO 80028- 
5319, phone (303) 673-6223, fax (303) 673- 
3353. 

CAV 92, Fourth Int’l Workshop on Com¬ 
puter-Aided Verification, June 29-July 1, 

Montreal. Contact Anindya Das, DIRO, 
Univ. of Montreal, 2900 boul. Edouard- 
Montpetit, CP 6128, succ. A. Montreal, 
Que., Canada H3C 3J7, phone (514) 343- 
7090, fax (514) 343-5834, e-mail das@iro. 
umontreai.ca. 

Atable 92, Second Int’l Workshop on Ar¬ 
ray Structures, June 29-July 1, Montreal. 
Contact Martine Gemme, Atable 92, 

DIRO, Univ. of Montreal, PO Box 6128, 
Station A, Montreal, Que., Canada H3C 
3J7, phone (514) 343-6602, fax (514) 343- 
5834, e-mail gemme@iro.umontreai.ca. 

IEEE Intelligent Vehicles 92, June 29-July 

1, Ypsilanti, Mich. Sponsor: IEEE Indus¬ 
trial Electronics Soc. Contact Ichiro Masa- 
ki, Computer Science Dept., GM Research 
Labs, 30500 Mound Rd., Warren, MI 
48090-9055, phone (313) 986-1466, fax 
(313) 986-9356, e-mail masaki@gmr.com. 

ECOOP 92, Sixth European Conf. on Ob¬ 
ject-Oriented Programming, June 29-July 

3, Utrecht, The Netherlands. Contact Gert 
Florijn, Software Eng. Research Centre, 

PO Box 424, 3500 AK Utrecht, The Neth¬ 
erlands, phone 31 (30) 322-640, fax 31 (30) 
341-249, e-mail ecoop92@serc.nl. 
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July 1992 


1992 Workshop on Fault-Tolerant 
Parallel and Distributed Systems, 
July 6-7, Amherst, Mass. Cosponsor: Univ. 
of Massachusetts at Amherst. Contact 
Marsha Lee, Computer Science Dept., 
Texas A&M Univ., H.R. Bright Bldg., Col¬ 
lege Station, TX 77843, phone (409) 862- 
2438, fax (409) 847-8578, e-mail marsha@ 
cs.tamu.edu; or Donald S. Fussell, Com¬ 
puter Science Dept., Univ. of Texas at 
Austin, TAY 2.124, Austin, TX 78712- 
1188, phone (512) 471-9719, fax (512) 471- 
7028, e-mail fussell@cs.utexas.edu. 


BNCOD 10,10th British Nat’l Conf. on 
Databases, July 6-8, Aberdeen, Scotland. 
Sponsor: British Computer Soc. Contact 
Peter Gray or Rob Lucas, BNCOD 10, 
Computing Science Dept., King’s College, 
Aberdeen, Scotland, UK AB9 2UB, phone 
(0224) 272-296, fax (0224) 487-048, e-mail 
bncodlO@uk.ac.abdn.csd. 

tgij CASE 92, Fifth Int’l Workshop on 
Computer-Aided Software Eng., July 
6-10, Montreal. Contact Gene Forte, 

CASE Outlook, 11830 Kerr Pkwy. #315, 
Lake Oswego, OR 97035, phone (503) 245- 
6880, fax (503) 245-6935, e-mail g.forte@ 
compmail.com; Nazim Madhavji, School of 
Computer Science, McGill Univ., 3480 
University St., Montreal, Que., Canada 
H3A 2A7, phone (514) 398-3740, fax (514) 
398-3883, e-mail case@softeng.cs. mcgill.ca; 
or John Jenkins, City Univ. of London, 
Business Systems Analysis Dept., London, 
UK, fax 44 (71)608-1270. 

APL 92, Int’l Conf. on APL, July 6-10, 

Leningrad, Russia. Cosponsors: Finnish 
APL Assoc, et al. Contact Lynne Shaw, 

417 Riverside Dr., Apt. 9B, New York, NY 
10025; or Erkki Juvonen, Finnish APL As¬ 
soc., Simontie 6 D 126,01350 Vantaa, Fin¬ 
land. 


Third Forum on Informatics, July 6-10, 

Hanoi, Vietnam. Sponsor: Vietnam Assoc, 
for Information Processing. Contact VAIP, 
36C Ly Nam De, Hanoi, Vietnam, phone 
84 (4) 254-219, fax 84 (4) 256-849. 


CASE Data Interchange Format, July 7, 

Montreal. Sponsor: CDIF Technical Com¬ 
mittee of the Electronic Industries Assoc. 
Contact Patti Rusher, EIA, 2001 Pennsyl¬ 
vania Ave. NW, Washington, DC 20006, 
phone (202) 457-4962, fax (202) 457-4985. 

ICCHP 92, Int'I Conf. on Computers for 
Handicapped Persons, July 7-9, Vienna. 
Cosponsors: Austrian Computer Soc. et al. 
Contact Wolfgang Zagler, Technical Univ. 
of Vienna, Inst, for Electronics, Gusshaus- 
straebe 27/359/IB, A-1040 Vienna, Aus¬ 
tria, phone 43 (1) 58801-3887, fax 43 (1) 
505-2666, e-mail zw@fortec.tuwien. ac.at, 
CompuServe 73457.1435. 

Iros 92, Fifth Int'I Conf. on Intelligent Ro¬ 
bots and Systems, July 7-10, Raleigh, N.C. 
Cosponsors: IEEE Industrial Electronics 
Soc., Robotics Soc. of Japan et al. Contact 


Avi Kak, School of Electrical Eng., Purdue 
Univ., West Lafayette, IN 47907, phone 
(317) 494-3551, fax (317) 494-6440, e-mail 
kak@ecn.purdue.edu; or Kazuo Tanie, Me¬ 
chanical Eng. Lab, MITI, 1-2 Namiki, 
Tsukuba-shi, Ibaraki-ken, 305, Japan, 
phone 81 (298) 54-2656, fax 81 (298) 54- 
2518, e-mail ml750@mel.go.jp. 

FTCS 22,22nd Int’l Symp. on Fault- 
N57 Tolerant Computing, July 8-10, Bos¬ 
ton. Cosponsors: Univ. of Massachusetts at 
Amherst et al. Contact Marsha Lee, Com¬ 
puter Science Dept., Texas A&M Univ., 
H.R. Bright Bldg., College Station, TX 
77843, phone (409) 862-2438, fax (409) 
847-8578, e-mail marsha@cs.tamu.edu; or 
Dhiraj K. Pradhan, Electrical and Comput¬ 
er Eng. Dept., Univ. of Massachusetts at 
Amherst, Amherst, MA 01003, phone 
(413) 545-0160, fax (413) 545-4611, e-mail 
pradhan@ecs.umass.edu. 

Financial Management for Data Process¬ 
ing Nat’l Conf., July 8-10, Scottsdale, Ariz. 
Sponsor: Financial Management for Data 
Processing. Contact Terence A. Quinlan, 
FMDP, PO Box 27543, San Francisco, CA 
94127, phone (415) 731-3706. 

URISA 92, July 12-16, Washington, D.C. 
Sponsor: Urban and Regional Information 
Systems Assoc. Contact URISA Secretari¬ 
at, 900 Second St. NE, Suite 304, Washing¬ 
ton, DC 20002, phone (202) 289-1685, fax 
(202) 842-1850. 

AAAI 92,10th Nat’l Conf. on Artificial In¬ 
telligence, and IAAI 92, Fourth Conf. on 
Innovative Applications of Artificial Intel¬ 
ligence, July 12-17, San Jose, Calif. Spon¬ 
sors: Am. Assoc, for Artificial Intelligence. 
Contact AAAI, 445 Burgess Dr., Menlo 
Park, CA 94025-3496, phone (415) 328- 
3123, fax (415) 321-4457, e-mail ncai@aaai. 
org or iaai@aaai.org. 

TTS V, Fifth Test Tech. Symp., July 14-16, 

Laurel, Md. Sponsor: US Army Test and 
Evaluation Command et al. Contact Bio- 
netics Meeting Support Div., Attn.: TTS V, 
10th Floor, Suite 1000, Harbour Centre 
Bldg., 2 Eaton St., Hampton, VA 23669, 
phone (804) 722-0330 ext. 826, fax (804) 
722-0894. 

ICS 92, Sixth ACM Int’l Conf. on Super- 
computing, July 19-24, Washington, D.C. 
Sponsor: ACM SIGArch. Contact Ken 
Kennedy, CITI Rice Univ., PO Box 1892, 
Houston, TX 77251, phone (713) 527-6009, 
e-mail ken@rice.edu; Constantine Poly- 
chronopoulos, CSRD, Univ. of Illinois, 104 
S. Wright St., Urbana, IL 61801, phone 
(217) 244-4144, e-mail cdp@csrd.uiuc.edu; 
Harry Wijshoff, Computer Science Dept., 
Utrecht Univ., Padualaan 14, 3584 CH 
Utrecht, The Netherlands, e-mail 
harryw@cs.ruu.nl; or Toshitugu Yuba, 
Electrotechnical Lab, 1-1-4 Umezono, 
Tsukuba, Ibaraki 305, Japan, e-mail 
yuba@etl.go.jp. 

1992 Int’l Symp. on Optical Applied Sci¬ 
ence and Eng., July 19-24, San Diego, Ca¬ 
lif. Sponsor: Int’l Sqc. for Optical Eng. 


Contact SPIE, PO Box 10, Bellingham, 

WA 98227-0010, phone (206) 676-3290, fax 
(206) 647-1445. 

Logic at Tver 92: Logical Foundation of 
Computer Science, July 20-24, Tver, Rus¬ 
sia. Cosponsors: IEEE et al. Contact M.A. 
Taitslyn, Univ. of Tver, 33 Zhelyabova St., 
Tver 170013, Russia. 

1992 Complex Systems Eng. Synthesis and 
Assessment Tech. Workshop, July 20-24, 

Silver Spring, Md. Cosponsors: Naval Sur¬ 
face Warfare Center Dahlgren Div., Office 
of Naval Tech. Contact Steve Howell, 
NSWCWODET, Code U33,10901 New 
Hampshire Ave., Silver Spring, MD 20903- 
5000, phone (301) 394-3987, fax (301) 394- 
1175, e-mail showell@nswc-wo.navy.mil. 

Coling 92,14th Inti Conf. on Computa¬ 
tional Linguistics, July 23-28, Nantes, 
France. Sponsor: Inti Committee on Com¬ 
putational Linguistics. Contact A. Zampol- 
li, Univ. di Pisa, ILC, via della Faggiola 32, 
1-56100, Pisa, Italy, phone 39 (50) 560-481, 
fax 39 (50) 589-055. 

^ Siggraph 92,19th Inti Conf. on 
V&y Computer Graphics and Interactive 
Techniques, July 26-31, Chicago. Sponsor: 
ACM. Contact Siggraph 92, 401 N. Michi¬ 
gan Ave., Chicago, IL 60611, phone (312) 
321-6830, fax (312) 321-6876, e-mail 
info92@siggraph.org. 

Colt 92, Fifth ACM Workshop on Compu¬ 
tational Learning Theory, July 27-29, Pitts¬ 
burgh. Contact Robert Daley or Betty 
Brannick, Computer Science Dept., 322 
Alumni Hall, Univ.of Pittsburgh, Pitts¬ 
burgh, PA 15260, phone (412) 624-5930 or 
8493, e-mail daley@cs.pitt.edu or 
brannick@cs.pitt.edu. 

Broadband Analog and Digital Opto-Elec- 
tronics, July 29-31, Santa Barbara, Calif. 
Sponsor: IEEE Lasers and Electro-Optics 
Soc. Contact IEEE LEOS, 445 Hoes Lane, 
PO Box 1331, Piscataway, NJ 08855-1331, 
phone (908) 562-3893, fax (908) 562-1571. 


August 1992 


| ^j^ | 17th Congress Workshop, Aug. 2-14, 

Washington, D.C. Sponsor: United 
Nations. Contact Lawrence W. Fritz, GE 
Aerospace, PO Box 8048-10A26, Philadel¬ 
phia, PA 19101. phone (215) 531-3205, fax 
(215) 962-3698. 

ECAI 92,10th European Conf. on Artifi¬ 
cial Intelligence, Aug. 3-7, Vienna. Spon¬ 
sor: Austrian Soc. for Artificial Intelli¬ 
gence. Contact ECAI 92 Conf. Office, 
ADV, Trattnerhof 2, A-1010 Vienna, Aus¬ 
tria, phone 43 (1) 533-0913-74, fax 43 (1) 
533-0913-77. 


® ASAP 92, Int’l Conf. on Application- 
Specific Array Processors, Aug. 4-7, 

Berkeley, Calif. Sponsor: Univ. of Califor¬ 
nia at Berkeley. Contact Jose Fortes, 


June 1992 


93 






School of Electrical Eng., Purdue Univ., 
West Lafayette, IN 47907, phone (317) 
494-3646, fax (317) 494-6440, e-mail 
fortes@ecn.purdue. edu; or Mary Stewart, 
EECS Dept., Cory Hall, Univ. of Califor¬ 
nia, Berkeley, CA 94720. 


(Qjl Hot Chips IV, Symp. on High-Per- 
formance Chips, Aug. 9-11, Stanford, 
Calif. Sponsor: IEEE Computer Soc. Tech¬ 
nical Committee on Microprocessors and 
Microcomputers. Contact Glen Langdon, 
phone (408) 459-2212, e-mail langdon@cse. 
ucsc.edu. 


35th Midwest Symp. on Circuits and Sys¬ 
tems, Aug. 9-12, Washington, D.C. Co¬ 
sponsors: George Washington Univ. et al. 
Contact Mona E. Zaghloul, Electrical Eng. 
and Computer Science Dept., George 
Washington Univ., Washington, DC 20052, 
phone (202) 994-3772, fax (202) 994-0227, 
e-mail zaghloul@seas.gwu.edu. 

4CCCG, 4th Canadian Conf. on Computa¬ 
tional Geometry, Aug. 10-14, St. John's, 
Nfld., Canada. Contact Cao An Wang, 
Computer Science Dept., Memorial Univ. 
of Newfoundland, St. John’s, Nfld., Canada 
A1C 5S7, phone (709) 737-4590, fax (709) 
737-2009, e-mail 4cccg@cs.mun.edu. 

I ^f^ j Crypto 92, Aug. 16-20, Santa Bar- 
bara, Calif. Sponsor: Int’l Assoc, of 
Cryptologic Research. Contact Spyros S. 
Magliveras, Computer Science and Eng. 
Dept., Univ. of Nebraska, Lincoln, NE 
68588-0115, phone (402) 472-5005, fax 
(402) 472-7767, e-mail spyros@helios.unl. 
edu. 


ICPP 92, 21st Int’l Conf. on Parallel Pro¬ 
cessing, Aug. 17-21, St. Charles, Ill. Spon¬ 
sor: Pennsylvania State Univ. Contact Tse- 
yun Feng, Penn State Univ., ECE Dept., 
EE East Bldg., University Park, PA 16802, 
phone (814) 863-1469, fax (814) 865-7065, 
e-mail tfeng@ecl.psu.edu. 


Computer-Based Design Environments 
Symp.-Workshop, Aug. 18-19, Baden-Ba¬ 
den, Germany. Contact Jens Pohl, CAD 
Research Unit, Cal Poly, San Luis Obispo, 
CA 93407, fax (805) 756-5986. 


Int’l Workshop on Distributed Data 
Management, Aug. 19-21, Edmon¬ 
ton, Alta., Canada. Cosponsors: Canadian 
Information Processing Soc. et al. Contact 
M. Tamer Ozsu, Computing Science Dept., 
Univ. of Alberta, Edmonton, Alta., Cana¬ 
da T6G 2H1, phone (403) 492-1071, fax 
(403) 492-1071. 


VLDB 92,18th Int’l Conf. on Very 
Large Data Bases, Aug. 23-27, Van¬ 
couver, B.C., Canada. Cosponsors: VLDB 
Endowment, Canadian Information Pro¬ 
cessing Soc. et al. Contact Paul Sorenson, 
Computer Science Dept., Univ. of Alberta, 
Edmonton, Alta., Canada T6G 2H1, phone 
(403) 492-4589, fax (403) 492-1071, e-mail 
vldb92@cs.ualberta.ca or sorenson@cs. 
ualberta.ca. 


Concur 92, Third Int’l Conf. on Concurren¬ 
cy Theory, Aug. 24-27, Stony Brook, N.Y. 
Sponsor: Nat’l Science Foundation. Con¬ 
tact Scott Smolka, Computer Science 
Dept., SUNY at Stony Brook, Stony 
Brook, NY 11794, phone (516) 632-8453, 
fax (516) 632-8334, e-mail sas@cs.sunysb. 


Int’l Workshop on Structural and Syntactic 
Pattern Recognition, Aug. 26-28, Bern, 
Switzerland. Sponsor: Int’l Assoc, for Pat¬ 
tern Recognition. Contact Horst Bunke, 
Inst, fiir Informatik und angewandte Math- 
ematik, Univ. of Bern, Langgassstrasse 51. 
CH-3012 Bern, Switzerland, phone 41 (31) 
654451 or 658681, fax 41 (31) 653965, 
e-mail bunke@iam.unibe.ch. 

ICPR 92,11th Int’l Conf. on Pattern Rec¬ 
ognition, Aug. 30-Sept. 3, The Hague, The 
Netherlands. Sponsor: Int’l Assoc, for Pat¬ 
tern Recognition. Contact ICPR Secretari¬ 
at, Delft Univ. of Tech., Electrical Eng. 
Dept., PO Box 5031, NL-2600 GA Delft, 
The Netherlands, phone 31 (15) 786-052, 
fax 31 (15) 622-000, e-mail icpr@et.tudelft. 
nl. 

FPL 92, Second Int’l Workshop on Field- 
Programmable Logic and Applications, 
Aug. 31-Sept. 2, Vienna. Sponsors: Vienna 
Univ. of Tech., Univ. of Kaiserslautern. 
Contact Herbert Griinbacher, Vienna 
Univ. of Tech., Treitlstrasse 3, A-1040, Vi¬ 
enna, Austria, phone 43 (1) 58801-8150, 
fax 43 (1) 569697, e-mail herbert@vlsivie. 
tuwien.ac.at; or Reiner Hartenstein, Univ. 
of Kaiserslautern, PO Box 3049, D-W-6750 
Kaiserslautern, Germany, phone 49 (631) 
205-2606, fax 49 (631) 205-2640, e-mail 
hartenst@rhrk.uni-kl.de. 


September 1992 

Conpar 92, Int’l Conf. on Parallel Process¬ 
ing, and VAPP V, Vector and Parallel 
Processors in Computational Science, Sept. 
1-4, Lyon, France. Cosponsors: Int’l Feder¬ 
ation for Information Processing et al. 
Contact Michel Cosnard, Ecole Normale 
Superieure de Lyon, Laboratoire de 
l’lnformatique du Parallelisme 46, allee 
d’ltalie, 69364 Lyon Cedex 07, France, 
phone (33) 7272-8037, fax (33) 7272-8080, 
e-mail cosnard@frensl61.bitnet. 

POS 5, Fifth Int'l Workshop on Persistent 
Object Systems, Sept. 1-4, San Miniato, 
Pisa, Italy. Cosponsors: Univ. of Pisa, 

Univ. of St. Andrews (UK). Contact Anto¬ 
nio Albano, Dip. di Informatica, Univ. di 
Pisa, 56126 Pisa, Italy, fax 39 (50) 510226, 
e-mail pos5@di.unipi.it. 

Third Int’l Workshop on VLSI for Artifi¬ 
cial Intelligence and Neural Networks, 

Sept. 2-4, Oxford, England. Sponsor: Univ. 
of Oxford. Contact Jose G. Delgado-Frias, 
Electrical Eng. Dept., State Univ. of New 
York at Binghamton, Binghamton, NY 
13902-6000, phone (607) 777-4806, fax 


(607) 777-4822, e-mail delgado@bingvaxu. 
cc.binghamton.edu. 

Third Int’l Conf. on Algebraic and Logic 
Programming, Sept. 2-4, Pisa, Italy. Con¬ 
tact H616ne Kirchner. CRIN and INRIA- 
Lorraine, BP 239, Campus Scientifique, 
54506 Vandoeuvre-les-Nancy Cedex, 
France, e-mail hkirchner@loria.crin.fr. 

Dexa 92, Third Int’l Conf. on Database 
and Expert Systems Applications, Sept. 2- 

4, Valencia, Spain. Cosponsors: Technical 
Univ. of Valencia et al. Contact Roland 
Wagner. FAW, Univ. of Linz. A4040 Linz, 
Austria, phone 43 (732) 2468-791, fax 43 
(732) 243-989, e-mail a4423dab@awiunlll. 
bitnet. 

Workshop on Neural Networks — 
Techniques and Applications, Sept. 
7-8, Liverpool, England. Cosponsors: 

IEEE United Kingdom-Republic of Ire¬ 
land Computer Chapter et al. Contact Kat¬ 
rina Houghton, Computer Science Dept., 
Univ. of Liverpool, Liverpool L69 3BX, 
England, UK, phone 44 (51) 794-3668, fax 
44 (51) 794-3715. 

EWSPT 92, Second European Workshop 
on Software Process Tech., Sept. 7-8, 

Trondheim, Norway. Cosponsors: Assoc. 
Francaise pour la Cybernetique Econo- 
mique et Technique et al. Contact Jean- 
Claude Derniame, Centre de Recherche en 
Informatique de Nancy, Campus scien¬ 
tifique B.P. 239, F-54506 Vandoeurve Les 
Nancy, France, phone 33 (83) 413-052, fax 
33 (83) 413-079, e-mail derniame@loria. 
crin.fr. 


Euro DAC 92, European Design Au¬ 
tomation Conf., Sept. 7-10, Ham¬ 
burg, Germany. Cosponsors: IEEE Circuit 
and Systems Soc. et al. Contact A. Zylber- 
sztejn. Bull SA, 121 Ave. De Malakoff, 
75116 Paris, France, phone 33 (14) 502- 
9583, fax 33 (14) 502-9307. 

Congress 92, 12th World Computer Con¬ 
gress, Sept. 7-11, Madrid. Sponsor: Int’l 
Federation for Information Processing. 
Contact Grupo Geyseco, Congress 92, 
Mauricio Legendre, 4-8.°G., E-28046 Mad¬ 
rid, Spain, fax 34 (1) 323-4936, e-mail 
ifip92@dit.upm.es. 

Eurographics 92, Sept. 7-11, Cambridge, 
England. Sponsor: Eurographics Assoc. 
Contact Jane Thorp, EG 92, Conf. Secre¬ 
tariat, The Registry, Univ. of East Anglia, 
Norwich NR4 7TJ, England, phone 44 
(603) 592-802, fax 44 (603) 250-035, e-mail 
eg92-organiser@uk.ac.uea.sys. 

ICIP 92, Second Singapore Int'l Conf. on 
Image Processing, Sept. 7-11, Singapore. 
Cosponsors: IEEE Singapore Section et al. 
Contact Technical Programme Chair, ICIP 
92, IEEE Singapore Section, 200 Jalan Sul¬ 
tan, #11-03 Textile Centre, Singapore 0719, 
phone (65) 291-9690, fax (65) 292-8596. 

Second European Modula-2 Conf., Sept. 8- 

9, Leicester, England. Sponsor: Leicester 
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Polytechnic. Contact Sue Brooks, Leicester 
Polytechnic, Marketing Centre, PO Box 
143, Leicester LEI 9BH, England, phone 
44 (0533) 577-577, fax 44 (0533) 549-972; or 
M. Al-Akaida, phone 44 (0533) 577-098, 
fax 44 (0533) 577-052, e-mail mma.uk.ac. 


Modeling, Sept. 16-18, Edinburgh, Scot¬ 
land. Sponsors: Int’l Federation for Infor¬ 
mation Processing Working Group 7.3, 
British Computer Soc. Contact Margaret 
Davis, Edinburgh Univ., Edinburgh EH9 
3JZ, Scotland, phone 44 (31) 650-5128, fax 
44 (31) 667-7209, e-mail mda@cs.ed.ac.uk. 


® HPDC 1, First Int’l Symp. on High- 
Performance Distributed Computing, 
Sept. 9-10, Syracuse, N.Y. Cosponsor: Syr¬ 
acuse Univ. Contact Geoffrey C. Fox, 
NPAC, Syracuse Univ., Rm. 3-131, 111 
College PL, Syracuse, NY 13244-4100, 
phone (315) 443-4741, fax (315) 443-1973, 
e-mail hpdc@nova.npac.syr.edu. 


AICS 92, Fourth Irish Conf. on Artificial 
Intelligence and Cognitive Science, Sept. 
10-11, Limerick, Ireland. Contact Kevin 
Ryan, Computer Science and Information 
Systems Dept., Univ. of Limerick, Ireland, 
fax 353 (61) 330316, e-mail aics92@ul.ie. 


LCN 92,17th Conf. on Local Com- 
puter Networks, Sept. 13-16, Minne¬ 
apolis. Sponsor: IEEE Computer Soc. 
Technical Committee on Computer Comm. 
Contact Steve Bell, Hughes LAN Systems, 
MS 392,1072 S. Saratoga Svale Rd., San 
Jose, CA 95129, phone (415) 966-7926, fax 
(415) 966-7990, e-mail sbell@hls.com. 


Conf. on Control and its Applications, 
Sept. 16-18, Minneapolis. Sponsor: Soc. for 
Industrial and Applied Math. Contact 
SIAM, 3600 University City Science Cen¬ 
ter, Philadelphia, PA 19104-2688, phone 
(215) 382-9800, fax (215) 386-7999, e-mail 
siam@wharton.upenn.edu. 


® WLI, IEEE Conf. on Wireless LAN 
Implementation, Sept. 17-18, Day- 
ton, Ohio. Contact James T. Geier, 685 N. 
Enon Rd., Yellow Springs, OH 45387, 
phone (513) 255-6224. 


KBSE 92, Seventh Knowledge-Based Soft¬ 
ware Eng. Conf., Sept. 20-23, Tysons Cor¬ 
ner, Va. Sponsor: Rome Lab. Contact 
Lewis Johnson, USC Information Sciences 
Inst., 4676 Admiralty Way, Marina del 
Rey, CA 90292-6695, phone (310) 822- 
1511. fax (310) 823-6714; or Barbara Radz- 
isz, Data and Analysis Center for Soft¬ 
ware, PO Box 120, Utica, NY 13503, phone 
(315) 336-0937, kbse7-request@cs.rpi.edu. 


Fifth Digital Signal Processing Workshop, 
Sept. 13-16, Starved Rock State Park, Ill. 
Sponsor: IEEE Signal Processing Soc. 
Contact Mark J.T. Smith, School of Elec¬ 
trical Eng., Georgia Inst, of Tech., Atlanta, 
GA 30332-0250, phone (404) 894-6291. 


ITC 92,1992 Int’l Test Conf., Sept. 
20-24, Baltimore. Cosponsor: IEEE 
Philadelphia Section. Contact Doris Tho¬ 
mas, 514 Pleasant Valley Blvd., Suite 3, Al¬ 
toona, PA 16602, phone (814) 941-4666, 
fax (814) 941-4668. 


SESS, Software Eng. Standards 
Symp., Sept. 13-17, Brighton, UK. 
Contact Takis Katsoulakos, Lloyd’s Regis¬ 
ter, Lloyd’s Register House, 29 Wellesley 
Rd., Croydon, CR0 2AJ, UK, phone (081) 
681-4774. 


BMVC 92, British Machine Vision Conf., 
Sept. 21-24, Leeds, UK. Sponsor: British 
Machine Vision Assoc. Contact Charlie 
Brown, School of Computer Studies, Univ. 
of Leeds, Leeds LS2 9JT, UK, phone 44 
(532) 335-463, fax 44.(532) 335-468, e-mail 
charlie@dcs.leeds.ac.uk. 


DCCA 3, Third Working Conf. on 
sg? Dependable Computing for Critical 
Applications, Sept. 14-16, Mondello, Italy. 
Sponsor: Int’l Federation for Information 
Processing Working Group 10.4. Contact 
Carl E. Landwehr, Code 5540, Naval Re¬ 
search Lab, Washington, DC 20375-5000, 
phone (202) 767-3381, fax (202) 404-7942; 
or Luca Simoncini, Dipartimento di Ingeg- 
neria dell’Informazione, Univ. of Pisa, Via 
Diotisalvi 2, 56100 Pisa, Italy, phone 39 
(50) 593-443 or 550-100, fax 39 (50) 554- 
342, e-mail simon@icnucevm.cnuce.cnr.it. 


ICARCV 92, Second Int’l Conf. on 
Automation, Robotics, and Comput¬ 
er Vision, Sept. 15-18, Singapore. Cospon¬ 
sors: Singapore Institution of Engineers 
et al. Contact ICARCV Secretariat, Asso¬ 
ciated Conventions and Exhibitions, 204 
Bukit Timah Rd., #04-00, Boon Liew 
Bldg., Singapore 0922, phone (65) 799- 
5470, fax (65) 791-2687, e-mail emital@ 
ntuvax.bitnet. 


ASIC 92, Fifth IEEE Int’l Conf. on 
Application-Specific Integrated Circuits, 
Sept. 21-25, Rochester, N.Y. Sponsor: 
IEEE Rochester Section. Contact Lynne 
M. Engelbrecht, 170 Mt. Read Blvd., 
Rochester, NY 14611, phone (716) 328- 
2310, fax (716) 436-9370; or Y. Tim Tsia, 
Eastman Kodak, MC-0201S, 1669 Lake 
Ave., Bldg. 81.454/KRL, Rochester, NY 
14650-2015, phone (716) 722-4896, fax 
(716) 722-9053. 


Compsac 92,16th Int’l Computer 
Software and Applications Conf., 
Sept. 22-25, Chicago. Contact Stephen 
Yau, Univ. of Florida, CIS Dept., Rm. 301, 
Gainesville, FL 32611, phone (904) 335- 
8006. 


PRICAI, Second Pacific Rim Int’l 
Conf. on Artificial Intelligence, Sept. 

23-25, Sungdong-ku, Korea. Cosponsors: 
Korea Information Science Soc. et al. Con¬ 
tact Jim Hyung Kim, Korea Advanced 
Inst, for Science and Tech., Center for Ar¬ 
tificial Intelligence Research, 373-1 Ku- 
song-dong, Yusong-ku, Taejon, 305-701, 


Korea, phone 82 (42) 829-3517, fax 82 (42) 
829-8700, e-mail jkim@cair.kaist.ac.kr. 


Ifrfil DT 92, Int’l Conf. on Data Transmis- 
NS' sion, Sept. 23-25, London. Sponsor: 
Institution of Electrical Engineers. Contact 
Alan Clark, Dowty Communications, May- 
ze House, Westmead, Swindown SN5 7YT, 
phone 44 (0793) 511-789, fax 44 (0793) 
511-683. 


Fifth Int’l Conf. on Putting into Practice 
Methods and Tools for Information System 
Design, Sept. 23-25, Nantes, France. Con¬ 
tact Henri Habrias, Liana, IUT, 3 rue MI 
Joffre, 44041 Nantes Cedex 01, France, 
phone (33) 4030-6056, fax (33) 4030-6001, 
e-mail habrias@naiut.dnet@ciripa.circe.fr. 

/gjj) IWOOOS 92, Int’l Workshop on Ob- 
ject Orientation in Operating Sys¬ 
tems, Sept. 24-25, Paris. Sponsor: Institut 
National de Recherche en Informatique et 
en Automatique. Contact Roy Campbell, 
Univ. of Illinois, Computer Science Dept., 
2413 Digital Lab, 1304 W. Springfield, 

Ave., Urbana, IL 61801, phone (217) 333- 
3328, e-mail roy@cs.uiuc.edu or eric.diku. 
dk. 


13th Int’l Symp. on Electronics Manufac¬ 
turing Tech., Sept. 28-30, Baltimore. Co¬ 
sponsors: IEEE Components, Hybrids, and 
Manufacturing Tech. Soc., Electronic In¬ 
dustries Assoc. Contact Bill Moody, 2529 
Eaton Rd., Wilmington, DE 19810, phone 
(302) 478-4143, fax (302) 478-7057. 


Fifth Int’l Workshop on Protocol Test Sys¬ 
tems, Sept. 28-30, Montreal. Contact Gre¬ 
gory V. Bochmann, Rachida Dssouli, or 
Anindya Das, Univ. de Montreal, Dept. 
d’lRO, CP 6128, succ. A, Montreal, Que., 
Canada H3C 3J7, fax (514) 343-5834, 
e-mail iwpts@niro.umontreal.ca. 


|Qj) Graphicon, Computer Graphics in 
Science and Arts, Sept. 28-Oct. 3, 

Moscow, Russia. Cosponsor: ACM. Con¬ 
tact Yury Golubev, Keldysh Inst, of Ap¬ 
plied Math, Miusskaya Sq. 4, Moscow 
125047, Russia, phone (095) 250-7817. 


® Int’l Workshop on Hardware-Soft¬ 
ware Codesign, Sept. 30-Oct. 2, Estes 
Park, Colo. Cosponsors: IEEE Computer 
Soc., IEEE Circuits and Systems Soc. Con¬ 
tact Joanne E. DeGroat, Ohio State Univ., 
205 Dreese Lab, 205 Neil Ave., Columbus, 
OH 43210, phone (614) 292-2439, e-mail 
degroat@ee.eng.ohio-state.edu; or Alfred 
E. Dunlop, AT&T Bell Labs, 600 Moun¬ 
tain Ave., Murray Hill, NJ 07974, phone 
(908) 582-6570, e-mail aed@allegra.att. 


30th Allerton Conf. on Comm., Control, 
and Computing, Sept. 30-Oct. 2, Monticel- 
lo, Ill. Sponsor: Univ. of Illinois at Urbana- 
Champaign. Contact Paul Van Dooren, 
Univ. of Illinois, Coordinated Science Lab, 
1101 W. Springfield Ave., Urbana, IL 
61801, phone (217) 333-0656, e-mail 
vdooren@uicsl.csl.uiuc.edu; or Mark 
Spong, Univ. of Illinois, Coordinated Sci¬ 
ence Lab, 1101 W. Springfield Ave., Urba- 
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na, IL 61801, phone (217) 333-4281, e-mail 
spong@lagrange.csl.uiuc.edu. 


October 1992 


Second Int’l Workshop on Respon¬ 
ds? sive Computer Systems, Oct. 1-2, 

Saitama, Japan. Sponsor: US Office of Na¬ 
val Research. Contact Miroslaw Malek, 
Electrical and Computer Eng. Dept., Univ. 
of Texas, Austin, TX 78712, phone (512) 
471-5704, fax (512) 471-0954, e-mail 
malek@emx.utexas.edu; or Tohru Kikuno, 
Information and Computer Science Dept., 
Osaka Univ., 1-1, Machikaneyama-cho, 
Toyonaka-shi, Osaka, 560, Japan, phone 81 
(6) 844-1151, fax 81 (6) 841-9741, e-mail 
kikuno@ics.osaka-u.ac.ip. 


Fifth ISMM Int’l Conf. on Parallel and 
Distributed Computing and Systems, Oct. 
1-3, Pittsburgh. Sponsors: Int’l Soc. for 
Mini and Microcomputers, Pittsburgh Su¬ 
percomputing Center. Contact Zary Segall, 
Computer Science Dept., Carnegie Mellon 
Univ., Pittsburgh, PA 15213-3890, phone 
(412) 268-3736. 


Sixth Software Eng. Inst. Conf. on 
vl? Software Eng. Education, Oct. 5-6, 
and 11th SEI Educator Development 
Workshop, Oct. 7, San Diego, Calif. Co¬ 
sponsor: Software Eng. Inst. Contact Carol 
Sledge, SEI, Carnegie Mellon Univ., Rm. 
4206, Pittsburgh, PA 15213-3890, phone 
(412) 268-7708, fax (412) 268-5758, e-mail 
cas@sei.cmu.edu. 


11th Symp. on Reliable Distributed 

vl? Systems, Oct. 5-7, Houston. Cospon¬ 
sors: IEEE Computer Soc. Technical Com¬ 
mittee on Distributed Processing et al. 
Contact Thomas F. Lawrence, Rome Lab/ 
C3AB, Bldg. 3, Griffiss Air Force Base, 
NY 13441, phone (315) 330-2158, fax (315) 
330-3911; or Kishor S. Trivedi, Electrical 
Eng. Dept., Duke Univ., Durham, NC 
27706, phone (919) 660-5269, e-mail kst@ 
egr.duke.edu. 


2ICSQ, Second Int’l Conf. on Software 
Quality, Oct. 5-7, Triangle Research Park, 
N.C. Sponsor: Am. Soc. for Quality, Soft¬ 
ware Div. Contact Sue McGrath, SAS 
Inst., SAS Campus Dr., Cary, NC 27513, 
phone (919) 677-8000, e-mail sassam@dev. 
sas.com; or John E. Lowe, Litton Comput¬ 
er Services, 4020 Executive Dr., Dayton, 
OH 45430, phone (513) 429-6458. 


Int’l Conf. on Signals, Data, and Systems: 
Modeling, Simulation, and Control, Oct. 5- 

7, Hefei, China. Cosponsors: Int’l Assoc, 
for the Advancement of Modeling and 
Simulation Technology in Enterprises et 
al. Contact G. Mesnard, AMSE, 16 Av. 
Grange Blanche, 69160 Tassin-la-Demi- 
Lune, France, fax (33) 78-34-54-17; or (in 
China) Bao Yuanlu, Automation Dept., 
Univ. of Science and Tech, of China, 

Hefei, Anhui, 230026, fax (0551) 331-760. 


Advanced Study Inst, on Real-Time Com¬ 
puting, Oct. 5-18, Sint Maarten/St. Martin, 
Dutch/French Antilles. Sponsors: NATO 
et al. Contact Wolfgang A. Halang, Com¬ 
puter Science Dept., Univ. of Groningen, 
PO Box 800,9700 AV Groningen, The 
Netherlands, phone 31 (50) 63-3925, fax 31 
(50) 63-3800, e-mail halang@cs.rug.nl; or 
Alexander D. Stoyenko, Computer and In¬ 
formation Science Dept., New Jersey Inst, 
of Tech., University Heights, Newark, NJ 
07102, phone 596-5765, fax (201) 596-5777, 
e-mail alex@vienna.njit.edu. 


Brigitte Diraison, Al Lab, SWIFT s.c., 1 
Av. Adele, 1310 La Hulpe, Belgium, phone 
32 (2) 655-3153, fax 32 (2) 655-3785. 

ASPLOS 5, Fifth Conf. on Architec¬ 
tural Support for Programming Lan¬ 
guages and Operating Systems, Oct. 12-15, 

Boston. Sponsor: ACM. Contact Barry 
Flahive, Hewlett-Packard, Apollo Systems 
Div., 300 Apollo Dr., MS CHR 02 DE, 
Chelmsford, MA 01824, phone (508) 256- 
2471 or 6600, e-mail flahive@apollo.hp. 


ISSRE 92, Third Int’l Symp. on Soft¬ 
ware Reliability Eng., Oct. 7-9, Re¬ 
search Triangle Park, N.C. Cosponsors: 
IEEE Computer Soc. Technical Commit¬ 
tee on Software Eng. et al. Contact Mladen 
A. Vouk, Computer Science Dept., Box 
8206, North Carolina State Univ., Raleigh, 
NC 27695-8206, phone (919) 515-7886, fax 
(919) 515-5839, e-mail vouk@adm.csc.ncsu. 
edu. 

11th Int’l Conf. on the Entity Relationship 
Approach, Oct. 7-9, Karlsruhe, Germany. 
Cosponsors: Gesellschaft fur Informatik, 
ER Inst. Contact W. Stucky, Univ. of 
Karlsruhe, AIFB, PO Box 6980, D-W-7500 
Karlsruhe, Germany, phone 49 (721) 60- 
83-81-2, fax 49 (721) 69-37-17, e-mail wst@ 
aifb.uni-karlsruhe.de. 


VBC 92, Visualization in Biomedical Com¬ 
puting 1992, Oct. 13-16, Chapel Hill, N.C. 
Sponsor: Univ. of North Carolina at Chap¬ 
el Hill. Contact Mary B. Ducker, Comput¬ 
er Science Dept, Univ. of North Carolina 
at Chapel Hill, Box 3175, Sitterson Hall, 
Chapel Hill, NC 27599-3175, phone (919) 
962-1869, fax (919) 962-1799, e-mail 
ducker@cs.unc.edu. 

SIGDoc 92,10th SIGDoc Int’l Conf., Oct. 
13-16, Ottawa, Canada. Sponsors: ACM 
Special Interest Group on Documentation, 
Northern Telecom and Bell-Northern Re¬ 
search. Contact Assoc, for Computing Ma¬ 
chinery, 11 W. 42nd St., New York, NY 
10036, phone (212) 869-7440; or BNR, 
(613) 763-2134, fax (613) 763-2626, e-mail 
sigdoc92@bnr.ca. 


Milcom 92, Oct. 11-14, San Diego, Calif. 
Cosponsors: IEEE Comm. Soc. et al. Con¬ 
tact Milcom 92, General Dynamics Elec¬ 
tronics Div., PO Box 85106. San Diego. 

CA 92186-5106; Security Dept. MZ 7101- 
G, Milcom 92, General Dynamics Elec¬ 
tronics Div., PO Box 85227, San Diego, 

CA 92186-5227; or Dennis E. Litchfield, 
Office of the Assistant Secretary of De¬ 
fense (C 3 I), The Pentagon, Rm. 3D 228, 
Washington, DC 30301-3040. 

DX 92, Third Int’l Workshop on Principles 
of Diagnosis, Oct. 11-14, Seattle. Contact 
Ethan Scarl, MS 7L-64, Boeing Computer 
Services, PO Box 24346, Seattle, WA 
98124-0346 (not for courier delivery), 
phone (206) 865-3255, fax (206) 865-2964, 
e-mail ethan@atc.boeing.com: or Ethan 
Scarl, MS 7L-64, Boeing Computer Servic¬ 
es, 2760 160th Ave. SE, Bldg. 33-07, Belle¬ 
vue, WA 98008 (not for US mail delivery). 

ICCD 92, Int’l Conf. on Computer 
Design, Oct. 12-14, Cambridge, 

Mass. Cosponsor: IEEE Circuit and Sys¬ 
tems Soc. Contact IEEE Computer Soc., 
1730 Massachusetts Ave. NW, Washington, 
DC 20036-1903, phone (202) 371-1013, fax 
(202) 728-0884. 

1992 Nat’l Communications Forum, Oct. 
12-14, Chicago. Sponsor: Nat’l Eng. Con¬ 
sortium. Contact NEC, 303 E. Wacker Dr., 
Suite 740, Chicago, IL 60601, phone (312) 
938-3500, fax (312) 938-8787. 

1992 Int’l Bankai Workshop on Adaptive 
Intelligent Systems, Oct. 12-14, Brussels. 
Sponsor: Soc. for Worldwide Interbank Fi¬ 
nancial Telecommunications. Contact 


12th Int’l Conf. of the Chilean Computer 
Science Soc., Oct. 14-16, Santiago, Chile. 
Contact Sergio T. Mujica, Depto. de Inge- 
nierla Informatica, Univ. de Santiago de 
Chile, Casilla 10233, Santiago, Chile, 
phone 56 (2) 776-3511, fax 56 (2) 681-1422, 
e-mail mujica@pucing.bitnet. 

ICMC 92, 1992 Int’l Computer Music 
Conf., Oct. 14-18, San Jose, Calif. Contact 
ICMC 92, Drawer 104, Music Dept., 1 
Washington Sq., San Jose State Univ., San 
Jose, CA 95192-0095, phone (408) 924- 
4675, fax (408) 924-4773, e-mail icms@ 
sjsuvml.bitnet.edu. 

Seventh Int’l Software Process 

Workshop, Oct. 15-18, Yountville, 
Calif. Sponsor: Rocky Mountain Inst, of 
Software Eng. Contact Ian Thomas, Soft¬ 
ware Design and Analysis, 444 Castro St., 
Suite 413, Mountain View, CA 94041, 
phone (415) 694-1464. 

OOPSLA 92, Seventh Conf. on Object- 
Oriented Programming Systems, Languag¬ 
es, and Applications, Oct. 18-22, Vancou¬ 
ver, B.C., Canada. Sponsor: ACM. Contact 
John Pugh, School of Computer Science, 
Carleton Univ., Colonel By Drive, Ottawa, 
Ont., Canada K1S 5B6, phone (613) 788- 
4330, e-mail oopsla92@carleton.ca. 

Frontiers 92, Fourth Symp. on the 

Frontiers of Massively Parallel Com¬ 
putation, Oct. 19-21, McLean, Va. Cospon¬ 
sors: NASA Goddard Space Flight Center 
et al. Contact Pearl Wang, Computer Sci¬ 
ence Dept. George Mason Univ., 440 Uni¬ 
versity Dr., Fairfax, VA 22030-4444, phone 
(703) 993-1527, fax (703) 993-1521. 
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10th Pacific Northwest Software Quality 
Conf., Oct. 19-21, Portland, Ore. Contact 
Hilly Alexander, ADP Dealer Services 
Group, 2525 SW First Ave., Portland, OR 
97201-4760, phone (503) 294-4200. 

Visualization 92, Oct. 19-23, Boston. 

Sponsor: IEEE Computer Soc. Tech¬ 
nical Committee on Computer Graphics. 
Contact Bruce E. Brown, Oracle, 500 Ora¬ 
cle Pkwy., Box 659412, Redwood Shores, 
CA 94065, phone (415) 506-6202, fax (415) 
726-0983; or Gregory M. Nielson, Arizona 
State Univ., Rural Rd. and University 
Ave., Tempe, AZ 85287-5406, phone (602) 
965-2785, e-mail nielson@enuxva.eas.asu. 


Fourth Int’l Workshop on Foundations of 
Models and Languages for Data and Ob¬ 
jects, Oct. 19-23, Volkse, Germany. Co¬ 
sponsors: Gesellschaft fur Informatik, Eu¬ 
ropean Assoc, for Theoretical Computer 
Science. Contact Udo Lipeck, Inst, fur In¬ 
formatik, Univ. of Hannover, Lange Laube 
22, D-W-3000, Hannover 1, Germany, 
phone 49 (511) 762-4950, e-mail ul@ 
informatik.uni-hannover.de. 


FOCS, Foundations of Computer 
vS? Science, Oct. 25-27, Pittsburgh, Con¬ 
tact Gary Miller, School of Computer Sci¬ 
ence, Carnegie Mellon Univ., Pittsburgh, 
PA 15213-3890, phone (412) 268-2631 or 
(412) 268-2526. 

26th Asilomar Conf. on Signals, Sys- 
terns, and Computers, Oct. 26-28, Pa¬ 
cific Grove, Calif. Cosponsors: Naval Post¬ 
graduate School et al. Contact Neil K. Jab- 
Ion, AT&T Bell Labs, 200 Laurel Ave., 
Rm. 1G-540, Middletown, NJ 07748-4801, 
phone (908) 957-2011, fax (908) 957-7943, 
e-mail nkj@mtqub.att.com. 


KR 92, Third Int’l Conf. on Principles of 
Knowledge Representation and Reason¬ 
ing, Oct. 26-29, Cambridge, Mass. Spon¬ 
sors: Am. Assoc, for Artificial Intelligence 
et al. Contact William Swartout, Informa¬ 
tion Sciences Inst., Univ. of Southern Cali¬ 
fornia, 4676 Admiralty Way, Marina del 
Rey, CA 90292-6695, phone (310) 822- 
1511, fax (310) 823-6714, e-mail swartout@ 
isi.edu; or Bernhard Nebel, DFKI, Stuhl- 
stazenhausweg 3, D-W-6600 Saarbruecken, 
Germany, phone 49 (681) 302-5254, fax 49 
(681) 302-5341, e-mail nebel@dfki.uni-sb. 
de. 


Fifth Workshop on Software Reuse, Oct. 
26-29, Palo Alto, Calif. Contact Martin 
Griss, Hewlett-Packard Labs, 1501 Page 
Mill Rd., Palo Alto, CA 94304-1126, phone 
(415) 857-8715, fax (415) 857-8526, e-mail 
griss@hpl.hp.com. 


Third Eurographics Workshop on Object- 
Oriented Graphics, Oct. 28-30, Champery, 
Switzerland. Sponsor: Eurographics, Univ. 
of Geneva. Contact Vicki de Mey or Xavi¬ 
er Pintado, Centre Universitaire d'lnfor- 
matique, Univ. of Geneva, 12 rue du Lac, 
1207 Geneva, Switzerland, phone 41 (22) 
787-6586, fax 41 (22) 735-3905, e-mail 
eoog@cui.unige.ch. 


Fourth NASA Symp. on VLSI Design, 

Oct. 29-30, Coeur d’Alene, Idaho. Cospon¬ 
sors: Spokane, Washington, IEEE Section, 
Univ. of Idaho NASA Space Eng. Re¬ 
search Center. Contact Sterling Whitaker, 
NASA SERC, Univ. of Idaho, Moscow, ID 
83843, phone (208) 885-6500, fax (208) 
885-6840, e-mail swhitaker@grieg.mrc. 
uidaho.edu. 


November 1992 


ISCIS 7, Seventh Int’l Symp. on 
Computer and Information Sciences, 
Nov. 2-4, Antalya, Turkey. Cosponsors: 
IEEE Computer Soc. Turkey Chapter et 
al. Contact Erol Gelenbe, Ecole des Hau- 
tes Etudes en Informatique, 45 rue des 
Saints-Peres, 75006 Paris, France, phone 33 
(1) 4286-2136, fax 33 (1) 4286-2231, e-mail 
erol@ehei.ehei.fr; or Nese Yalabik, Com¬ 
puter Eng. Dept., Middle East Technical 
Univ., 06531 Ankara, Turkey, phone 90 (4) 
223-7100, ext. 2079, fax 90 (4) 286-8624, 
e-mail iscis@trmetu.bitnet. 

IJCNN 92, Int’l Joint Conf. on Neural Net¬ 
works, Nov. 3-6, Beijing, China. Cospon¬ 
sors: IEEE Neural Networks Council et al. 
Contact IJCNN 92 Secretariat, Rm. 2307, 
13th Floor, 12 Nongzhanguan Nanlu, Bei¬ 
jing, 100026, China, phone 86 (1) 500-1144, 
ext. 2307, fax 86 (1) 500-5233. 

DFT 92,1992 IEEE Int’l Workshop on De¬ 
fect and Fault Tolerance in VLSI Systems, 
Nov. 4-6, Dallas. Contact D.M.H. Walker, 
Electrical and Computer Eng. Dept., Carn¬ 
egie Mellon Univ., Pittsburgh, PA 15213- 
3890, phone (412) 268-8522, fax (412) 268- 
2860, e-mail dmw@ece.cmu.edu. 


Ave., Suite 302, Bethesda, MD 20814, 
phone (301) 657-1291, fax (301) 657-1296. 


ICCAD 92, Int’l Conf. on Computer- 
v5 V Aided Design, Nov. 8-12, Santa 
Clara, Calif. Cosponsors: IEEE Circuit and 
Systems Soc., ACM. Contact MP Associ¬ 
ates, 7490 Clubhouse Rd., Suite 102, Boul¬ 
der, CO 80301, phone (303) 530-4562, fax 
(303) 530-4334; or Harry Stephanov, Cen¬ 
ter for Information and Robotics, Rens¬ 
selaer Polytechnic Inst., Troy, NY 12181, 
phone (518) 276-6156. 


Gomac 92, Government Microcircuit Ap¬ 
plications Conf., Nov. 8-12, Las Vegas, 
Nev. Cosponsors: US Dept, of Defense et 
al. Contact Nancy K. Welker, Nat’l Securi¬ 
ty Agency, Attn.: Rl-Airport Square #5, 
900 Savage Rd., Ft. George G. Meade, MD 
20755-6000, phone (301) 859-6690, fax 
(301) 964-0620. 


CSM 92,1992 Conf. on Software 
v§? Maintenance, Nov. 9-12, Orlando, 
Fla. Contact Vaclav Rajlich, Computer Sci¬ 
ence Dept., Wayne State Univ., Detroit, 

MI 48202, phone (313) 577-5423, fax (313) 
577-6868, e-mail vtr@cs.wayne.edu. 

Systems Test and Diagnosis Work- 
shop, Nov. 9-12, Freiburg, Germany. 
Contact Colin Maunder, BT Labs. Martle- 
sham Heath, Ipswich IP5 7RE, UK, phone 
44 (473) 642-706, fax 44 (473) 642-157. 


JICSLP 92, Joint Int’l Conf. and Symp. on 
Logic Programming, Nov. 9-13, Washing¬ 
ton, D.C. Cosponsors: Assoc, for Logic 
Programming, Univ. of Maryland Inst, for 
Advanced Computer Studies. Contact Jo¬ 
hanna Weinstein, Univ. of Maryland, 
IACS, A.V. Williams Bldg., College Park, 
MD 20742, phone (301) 405-6722, e-mail 
johanna@umiacs.umd.edu. 


SimTec 92, Int’l Simulation Tech. Conf., 
Nov. 4-6, Houston. Sponsors: Soc. for 
Computer Simulation et al. Contact Mary 
Lou Padgett, Auburn Univ., 1165 Owens 
Rd., Auburn, AL 36830, phone (205) 821- 
2472, fax (619) 277-3930, e-mail 
mpadgett@eng.auburn.edu. 

PDC 92,1992 Participatory Design Conf., 
Nov. 6-7, Cambridge, Mass. Sponsor: Com¬ 
puter Professionals for Social Responsibili¬ 
ty. Contact Ellen White, Bellcore RRC- 
1H229, 444 Hoes Lane, Piscataway, NJ 
08854, phone (908) 699-4449, fax (908) 
336-2275, e-mail eaw3@taichi.cc.bellcore. 


TAI 92, Fourth Int’l IEEE Conf. on 
Tools with Artificial Intelligence, 
Nov. 10-13, Arlington, Va. Contact Niko- 
laos G. Bourbakis, SUNY at Binghamton, 
Electrical Eng. Dept., Binghamton, NY 
13902-6000, phone (607) 777-4856 or 2165, 
fax (607) 777-4822, e-mail bourbaki@ 
bingvaxu.cc.binghamton.edu. 

134th Technical Conf. of the Soc. of Mo¬ 
tion Picture and Television Engineers, 

Nov. 10-13, Toronto. Contact Marilyn 
Waldman, SMPTE, 595 W. Hartsdale Ave., 
White Plains, NY 10607, phone (914) 761- 
1100. 


First Int’l Conf. on Information and 
Knowledge Management, Nov. 8-11, 

Baltimore. Sponsor: Int’l Soc. of Mini- and 
Microcomputers. Contact Timothy W. Fi- 
nin or Tony Nircio, C/S Dept., Univ. of 
Maryland, 5401 Wilkens Ave., Baltimore, 
MD 21228-5398, phone (410) 455-3522, fax 
(410) 455-3969. 


SCAMC, 16th Symp. on Computer Appli¬ 
cations in Medical Care, Nov. 8-11, Balti¬ 
more. Sponsor: Am. Medical Informatics 
Assoc. Contact AMIA, 4915 St. Elmo 


Second Workshop on Management 
vfix of Replicated Data, Nov. 12-13, 

Monterey, Calif. Sponsor: IEEE Computer 
Soc. Technical Committee on Operating 
Systems and Application Environments. 
Contact Jehan-Francois Paris, Computer 
Science Dept., Univ. of Houston, 4800 Cal¬ 
houn Rd., Houston, TX 77204-3475, phone 
(713) 749-3943, fax (713) 749-2378, e-mail 
paris@cs.uh.edu. 


UIST 92, Fifth Symp. on User Interface 
Software and Tech., Nov. 15-18, Monterey, 
Calif. Sponsor: ACM. Contact Jock Mack- 


June 1992 


97 







inlay, Xerox PARC, 3333 Coyote Hill Rd., 
Palo Alto, CA 94303, phone (415) 494- 
4335, fax (415) 494-4777, e-mail 
mackinlay.parc@xerox.com. 


ASM 92, Third Int’l Conf. on Applications 
of Software Measurement, Nov. 16-19, San 

Diego, Calif. Sponsors: Data Processing 
Management Assoc, et al. Contact David 
Gelperin, Software Quality Eng., 2738 
Winnetka Ave. N, New Hope, MN 55427, 
fax (612) 591-1534; or Software Quality 
Eng., 3000-2 Hartley Rd., Jacksonville, FL 
32257, phone (904) 268-8639, fax (904) 
268-0733. 


Supercomputing 92, Fifth High-Per- 
formance Computing and Comm. 
Conf., Nov. 16-20, Minneapolis. Cospon¬ 
sor: ACM. Contact IEEE Computer Soc., 
1730 Massachusetts Ave. NW, Washington, 
DC 20036-1903, phone (202) 371-1013, fax 
(202) 728-0884. 


ATS 92, First Asian Test Symp., 

Nov. 26-27, Hiroshima, Japan. Con¬ 
tact Hideo Fujiwara, Computer Science 
Dept., Meiji Univ., 1-1-1 Higashimita, 
Tama-ku, Kawasaki 214, Japan, fax 81 (44) 
934-7912, e-mail fujiwara@cs.meiji.ac.jp; or 
Kozo Kinoshita, Applied Science Dept., 
Osaka Univ., 2-1 Yamadaoka, Suite 565, 
Japan, phone 81 (06) 877-5111, fax 81 (06) 
877-2900. 


Time Systems et al. Contact Wei Zhao, 
Computer Science Dept., Texas A&M 
Univ., College Station, TX 77843-3112, 
phone (409) 845-5098, fax (409) 847-8578, 
e-mail zhao@cs.tamu.edu. 


Technology 2002, Third Nat’l Technology 
Transfer Conf., Dec. 1-3, Baltimore. Co¬ 
sponsors: NASA et al. Contact Leonard A. 
Ault, Code CU, NASA Headquarters, 600 
Independence Ave. SW, Washington, DC 
20546, phone (703) 557-5598, fax (703) 
557-8186. 

Ninth TRON Project Symp., Dec. 

j-4, Tokyo. Sponsor: TRON Assoc. 
Contact Koji Nihei, Oki Electric Industry 
Co., 7-12 Toranomon, 1-Chome, Minato- 
ku, Tokyo 105, Japan, phone 81 (3) 3501- 
3111, fax 81 (3) 3581-3349; or Eiichi Ohno, 
Headquarters R&D, Mitsubishi Electric 
Corp., 2-2-3 Marunouchi, Tokyo 100, Ja¬ 
pan, phone 81 (3) 3218-2163, fax 81 (3) 
3218-2188. 


Micro 25, 25th Int’l Symp. on Micro- 
architecture, Dec. 1-4, Portland, Ore. 
Cosponsors: IEEE Computer Soc. Techni¬ 
cal Committee on Microprogramming and 
Microarchitecture, ACM. Contact Wen- 
mei W. Hwu, Electrical and Computer 
Eng. Dept., Univ. of Illinois, 1101 W. 
Springfield Ave., Urbana, IL 61801, phone 
(217) 244-8270, fax (217) 244-5686, e-mail 
hwu@crhc.uiuc.edu. 


nandale, VA 22003-2500, phone (703) 750- 
3910; or Herb Schwetman, MCC, 3500 W. 
Balcones Center Dr., Austin, TX 78759- 
6509, phone (512) 338-3428. 

ICS 92, Int’l Computer Symp., Dec. 13-15, 

Taichung, Taiwan, Republic of China. Co¬ 
sponsors: IEEE Taipei et al. Contact An- 
Chi Liu, Information Eng. Dept., Feng 
Chia Univ., Taichung, Taiwan, ROC, 
phone 886 (4) 252-2250 ext. 3700, e-mail 
fcut003@twnmoel0.bitnet; or Ben W. Wah, 
Coordinated Science Lab, Univ. of Illinois, 
1101 W. Springfield Ave., Urbana, IL 
61801, phone (217) 244-7175, e-mail wah@ 
manip.csl.uiuc.edu. 

ICSC 92, Second Int’l Computer Sci- 
ence Conf., Dec. 13-16, Hong Kong. 
Sponsor: IEEE Hong Kong Section Com¬ 
puter Chapter. Contact Ernest Lam, Com¬ 
puting Studies Dept., Hong Kong Baptist 
Univ., 224 Waterloo Rd., Kowloon, Hong 
Kong, phone (852) 339-7081, fax (852) 338- 
8014, e-mail ernest@bc750.hkbc.hk. 

Compugraphics 92, Second Int’l Conf. on 
Computational Graphics and Visualization 
Techniques, Dec. 14-18, Lisbon, Portugal. 
Sponsors: ACM et al. Contact Harold P. 
Santo, Civil Eng. Dept., IST-Advanced 
Technical Inst., Technical Univ. of Lisbon, 
Av. Rovisco Pais, 1096 Lisboa Codex, Por¬ 
tugal, phone 351 (1) 847-3421, fax 351 (1) 
89-7650. 


WACV, IEEE Workshop on Appli- 
NSZ cations of Computer Vision, Nov. 30- 
Dec. 2, Palm Springs, Calif. Contact Bir 
Bhanu, College of Eng., Univ. of Califor¬ 
nia, Riverside, CA 92521-0425, phone 
(714) 787-3954, fax (714) 787-3188. 


ACSAC 92, Eighth Computer Secu- 
rity Applications Conf., Nov. 30-Dec. 

4, San Antonio, Texas. Cosponsors: Aero¬ 
space Computer Security Associates et al. 
Contact Ronald Gove, Booz-Allen and 
Hamilton, 4330 East-West Hwy., Bethesda, 
MD 20814, phone (301) 951-2395, fax (301) 
907-4302, e-mail gove@dockmaster.ncsc. 
mil. 


NIPS 92, Sixth Conf. and Workshops on 
Neural Information Processing Systems, 
Nov. 30-Dec. 5, Denver (conference) and 
Vail, Colo, (workshops). For the confer¬ 
ence, contact Jack Cowan, Univ. of Chica¬ 
go, Math Dept., 5734 S. University Ave., 
Chicago, IL 60637. For the workshops, 
contact Gerald Tesauro, IBM TJ Watson 
Research Center, PO Box 704, Yorktown 
Heights, NY 10598, e-mail tesauro® 
watson.ibm.com. 


December 1992 


IEEE Workshop on Imprecise and 
Approximate Computation, Dec. 1, 

Phoenix, Ariz. Cosponsors: IEEE Comput¬ 
er Soc. Technical Committee on Real- 


RTSS 92,13th IEEE Real-Time Sys¬ 
tems Symp., Dec. 2-4, Phoenix, Ariz. 
Sponsor: IEEE Computer Soc. Technical 
Committee on Real-Time Computing. 
Contact Lui Sha, Software Eng. Inst., Car¬ 
negie Mellon Univ., 5000 Forbes Ave., 
Pittsburgh, PA 15213, phone (412) 268- 
5875, fax (412) 268-5758. 


NAFIPS 92, North Am. Fuzzy Information 
Processing Soc. Conf., Dec. 15-17, Puerto 
Vallarta, Mexico. Cosponsors: NASA et al. 
Contact Carla Armstrong, Software Tech. 
Branch/PT4, NASA Lyndon B. Johnson 
Space Center, Houston, TX 77058, phone 
(713) 483-9071, fax (713) 438-5200, e-mail 
carmstrong@gothamcity.jsc.nasa.gov. 


Int’l Workshop on Feature Interactions in 
Telecommunications Software Systems, 
Dec. 3-4, St. Petersburg, Fla. Contact Nan¬ 
cy D. Griffeth, Bellcore, MRE 2L-237, 445 
South St., Morristown, NJ 07962-1910, 
phone (201) 829-4538, fax (201) 829-5889, 
e-mail nancy@thumper.bellcore.com. 

ISAI, Fifth Int'l Symp. on Artificial Intelli¬ 
gence, Dec. 7-11, Cancun, Mexico. Spon¬ 
sor: Inst. Tecnologico y de Estudios Supe- 
riores de Monterrey. Contact Hugo Tera- 
shima, ITESM, Centro de Inteligencia Arti¬ 
ficial, Sucursal de Correos “J”, Monterrey, 
N.L. 64849, Mexico, phone 52 (83) 58-2000, 
ext. 5134, fax 52 (83) 58-1400, e-mail 
isai@teemtyvm.bitnet or terashim@mtecv2. 


ACM SIGSoft 92, Fifth Symp. on Software 
Development Environments, Dec. 9-11, 

Washington, D.C. Contact Herbert Weber, 
Fachbereich Informatik, Univ. of Dort¬ 
mund, Baroperstrasse 301, 4600 Dortmund 
50, Germany. 


Ijggj) WSC 92, Winter Simulation Conf., 
Dec. 12-16, Arlington, Va. Cospon¬ 
sors: Soc. for Computer Simulation et al. 
Contact Robert Crain, Wolverine Software 
Corp., 4115 Annandale Rd., Suite 200, An- 


Ninth Israeli Conf. on Artificial Intelli¬ 
gence and Computer Vision, Dec. 28-29, 

Tel Aviv. Sponsor: Israeli Information Pro¬ 
cessing Assoc. Contact Shimon Edelman, 
Applied Math and Computer Science 
Dept., Weizmann Inst, of Science, Rehovot 
76100, Israel, phone 972 (8) 344-122, fax 
972 (8) 342-856, e-mail edelman@wisdom. 
weizmann.ac.il; or Ehud Gudes, Computer 
Science Dept., Ben Gurion Univ., Beer 
Sheva 84105, Israel, phone 972 (57) 461- 
626, e-mail ehud@bengus.bitnet. 


January 1993 


VLSI Design 93, Sixth Int’l Conf. on 
VLSI Design, Jan. 3-6, Bombay, In¬ 
dia. Sponsor: VLSI Soc. of India. Contact 
Yashwant K. Malaiya, Computer Science 
Dept., Colorado State Univ., Fort Collins, 
CO 80523, phone (303) 491-7031, fax (303) 
491-2293, e-mail malaiya@ravi.cs.colostate. 
edu; or S.S.S.P. Rao, Computer Science 
and Eng. Dept., Indian Inst, of Tech., 
Powai, Bombay 400076, India, phone 91 
(22) 578-5708,2545, 2701, or 2714, fax 91 
(22) 578-3480, e-mail ssspr@cse.iitb.ernet. 


COMPUTER 






(gv IEEE Int’l Symp. on Requirements 
Eng., Jan. 4-6, San Diego, Calif. Con¬ 
tact Stephen F. Fickas, Univ. of Oregon, 
Computer and Information Science Dept., 
Eugene, OR 97403, phone (503) 346-3964, 
e-mail fickas@cs.uoregon.edu. 

Mascots 93, Int'I Workshop on Mod- 
eling, Analysis, and Simulation of 
Computer and Telecommunication Sys¬ 
tems, Jan. 17-20, La Jolla, Calif. Sponsors: 
Soc. for Computer Simulation et al. Con¬ 
tact Herb Schwetman, MCC, 3500 W. Bal- 
cones Center Dr., Austin, TX 78681, phone 
(512) 338-3428, fax (512) 338-3885, e-mail 
hes@mcc.com; Pat Dowd, Electrical and 
Computer Eng. Dept., SUNY, Buffalo, NY 
14260, phone (716) 636-2406, fax (716) 
636-3656, e-mail dowd@eng.buffalo.edu; or 
Kallol Bagchi, Inst, of Electronic Systems, 
Aalborg Univ., Fredrick Bajers Vej 7, DK 
9220 Aalborg Ost., Denmark, phone (45) 
98-15-85-22, e-mail kkb@vaxa.aud.auc.dk. 

ICSEE 93, Int’l Conf. on Simulation 
in Eng. Education, Jan. 17-20, La 

Jolla, Calif. Cosponsors: Soc. for Computer 
Simulation et al. Contact Hamid Vakilzadi- 
an. Electrical Eng. Dept., Univ. of Nebras- 
ka-Lincoln, Lincoln, NE 68588-0511, 
phone (402) 472-1977, fax (402) 472-4732, 
e-mail eerdvak@engvms.unl.edu; or 
Charles Knadler, IBM, Advanced Automa¬ 
tion Systems, 9201 Corporate Blvd., Rock¬ 
ville, MD 20850, phone (301) 640-3124, fax 
(301) 640-2136, e-mail knadlerc@wmavm7. 
vnet.ibm.com. 

Conf. on Simulation Applications in 
Business Management and MIS, Jan. 
17-20, La Jolla, Calif. Sponsor: Soc. for 
Computer Simulation. Contact Stuart 
Monroe, Computer Information Systems 
and Management Science, Metropolitan 
State College of Denver, Denver, CO 
80217-3362, phone (303) 556-8506, fax 
(303) 556-4429, e-mail monroe@zeno. 
msc.colorado.edu. 

ISIT 93,1993 IEEE Int’l Symp. on Infor¬ 
mation Theory, Jan. 17-22, San Antonio, 
Texas. Sponsor: IEEE Information Theory 
Soc. Contact Robert Gray, Electrical Eng. 
Dept., 133 Durand, Stanford Univ., Stan¬ 
ford. CA 94305, phone (415) 723-4001, fax 
(415) 723-8473, e-mail gray@isl.stanford. 
edu; or Richard E. Blahut, Mail Drop 
0600, IBM, Route 17C, Owego, NY 13827, 
phone (607) 751-2217. 

PDIS, Second Int’l Conf. on Parallel 
and Distributed Information Sys¬ 
tems, Jan. 20-23, San Diego, Calif. Cospon¬ 
sor: ACM. Contact Michael Lambert, 

NCR, E&M-SD, 16550 W. Bernardo Dr., 
MS 8001, San Diego, CA 92127, phone 
(619) 485-2376, fax (619) 485-2382; or 
Michael Carey, Computer Sciences Dept., 
Univ. of Wisconsin, 1210 W. Dayton St., 
Madison, WI 53706; or Patrick Valduriez, 
INRIA, Rocquencourt, 78153 Le Chesnay 
Cedex, France. 

IEEE Int’l Conf. on Wafer-Scale In- 
tegration, Jan. 20-23, San Francisco. 


Contact Peter W. Wyatt, phone (617) 981- 
7232, fax (617) 862-9057 (in the Americas); 
R. Mike Lea, phone 44 (0) 895-203221, fax 
44 (0) 895-258728 (in Europe); or Susumu 
Horiguchi, phone 81 (22) 222-1800, fax 81 
(22) 263-9418 (in Asia). 


February 1993 

IEEE VLSI Workshop, Feb. 7-10, 

Monterey, Calif. Contact Paul Co¬ 
hen, Advanced Hardware Architectures, 
PO Box 9669, Moscow, ID 83843, phone 
(208) 883-6000, fax (208) 883-8001. 

EDAC 93, Fourth European Design 

Automation Conf. and EuroASIC 
93, European Event in ASIC Design, Feb. 
22-25, Paris. Contact CEP Consultants, 26- 
28 Albany St., Edinburgh, EH1 3QH, Scot¬ 
land, phone 44 (31) 557-2478, fax 44 (31) 
557-5749. 


10th Int’l Zurich Symp. on Electromagnet¬ 
ic Compatibility, Mar. 9-11, Zurich, Swit¬ 
zerland. Cosponsors: IEEE Switzerland 
Chapter on Electromagnetic Compatibility 
et al. Contact Gabriel Meyer, ETH-Zen- 
trum-IKT, CH-8092 Zurich, Switzerland, 
phone 41 (1) 256-2790, fax 41 (1) 262-0943. 

12th IEEE Int’l Phoenix Conf. on 
Computers and Comm., Mar. 24-26, 

Scottsdale, Ariz. Contact James Weeldrey- 
er, Honeywell, 16404 N. Black Canyon 
Hwy., Phoenix, AZ 85023, phone (602) 
436-4813, fax (602) 436-4848, e-mail 
weeldrey@iasdvl.iasd.honeywell.com. 

IWSR 93, Second Int’l Workshop on 
Software Reusability, Mar. 24-26, 

Lucca, Italy. Cosponsors: ACM SIGSoft 
et al. Contact Ruben Prieto-Diaz, Software 
Productivity Consortium, 2214 Rock Hill 
Rd., Herndon, VA 22070, phone (703) 742- 
7107, fax (703) 742-7200. 

tjjji ASOM 93, Second Am. Symp. on 
Microelectronics, Mar. 27-28, Mem¬ 
phis, Tenn. Sponsor: Memphis State Univ. 
Contact Eliayeb S. Abuelyaman, Electrical 
Eng. Dept., Memphis State Univ., Mem¬ 
phis, TN 38152, phone (901) 678-2050, fax 
(901) 678-4180. 

£jj!) IEEE Infocom 93,12th Conf. on 
Computer Comm., Mar. 28-Apr. 1, 

San Francisco. Cosponsor: IEEE Comm. 
Soc. Contact Kenneth Vastola, ECSE 
Dept., Rensselaer Polytechnic Inst., Troy, 
NY 12180-3590, phone (518) 276-6074, 
e-mail infocom@ecse.rpi.edu. 


for Computer Simulation. Contact John A. 
Miller, Computer Science Dept., 415 Grad¬ 
uate Studies Research Center, Univ. of 
Georgia, Athens, GA 30602, phone (706) 
or (404) 542-3440, e-mail jam@pollux.cs. 
uga.edu. 

£§jj) ISADS 93,1993 Int’l Symp. on Au- 
tonomous Decentralized Systems, 
Mar. 30-Apr. 1, Kawasaki, Japan. Cospon¬ 
sors: Information Processing Soc. of Japan 
et al. Contact Stephen S. Yau, Univ. of 
Florida, Computer and Information Sci¬ 
ences Dept., 301 CSE Bldg., Gainesville, 
FL 32611-2024, fax (904) 392-1220, e-mail 
yau@cis.ufl.edu; or Kinji Mori, Systems 
Development Lab, Hitachi, 1099 Ohzenji, 
Asao, Kawasaki 215, Japan, fax 81 (44) 
966-6823, e-mail kmori@sdl.hitachi.co.jp. 


April 1993 

/jjfjN Third Int’l Symp. on Database Sys- 
vS?' terns for Advanced Application, Apr. 
6-8, Yusong-Ku Daejon, Korea. Sponsors: 
Korean Information Science Soc., Informa¬ 
tion Processing Soc. of Japan. Contact Hy- 
oung-Joo Kim or Sukho Lee, Computer 
Eng. Dept., Seoul Nat’l Univ., Shinlim- 
dong, Kwanak-ku, Seoul 150, Korea, 
phone 82 (02) 880-5327 (for Kim), 82 (02) 
880-5351 (for Lee), fax 82 (02) 887-0130, 
e-mail hjk@krsnuccl.bitnet. 

IPPS 93, Seventh Int’l Parallel Pro- 
\£p' cessing Symp., Apr. 13-16, Newport 
Beach, Calif. Cosponsor: ACM SIGArch. 
Contact Conferences Dept., IEEE Com¬ 
puter Soc., 1730 Massachusetts Ave. NW, 
Washington, DC 20036-1903, phone (202) 
371-1013, fax (202) 728-0884; or H.T. 

Kung, Computer Science Dept., Carnegie 
Mellon Univ., 5000 Forbes Ave., Pitts¬ 
burgh, PA 15213-3890, phone (412) 268- 
2568. 

|£|j\ RIDE-IMS 93, Third Int’l Workshop 

on Research Issues in Data Eng. — 
Interoperability in Multidatabase Systems, 
Apr. 18-20, Vienna. Cosponsor: Austrian 
Computer Soc. Contact Dimitrios Georga- 
kopoulos, GTE Labs, 40 Sylvan Rd., MS- 
62, Waltham, MA 02254, phone (617) 466- 
2522, fax (617) 890-9320, e-mail dimitris@ 
gte.com; Susan Urban, Computer Science 
Dept., Arizona State Univ., Tempe, AZ 
85287-5406, phone (602) 965-2784, fax 
(602) 965-2751, e-mail urban@asuvax.eas. 
asu.edu; or Elisa Bertino, Dip. di Mate- 
matica, Univ. di Genova, phone 39 (10) 
353-8034, e-mail bertino@icnucevm.cnuce. 


ICDE 93, Ninth Int’l Conf. on Data 
Eng., Apr. 19-23, Vienna. Contact 
Forouzan Golshani, CS&E, Arizona State 
Univ., Tempe, AZ 85287-5406, phone 
(602) 965-2855 or 3190, fax (602) 965-2751, 
e-mail golshani@asuvax.eas.asu.edu; or A. 
Min Tjoa, Inst, fur Statistik und Informa- 
tik, Liebiggasse 4, A-1010 Vienna, Austria, 
phone 43 (1) 43-2367, fax 43 (1) 43-0197, 
e-mail tjoa@ifs.univie.ac.at. 
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BOOK REVIEWS 


Editor: Alan Kaminsky, Rochester Institute of Technology, PO Box 9887, Rochester, NY 14623-0887 
(716) 475-5255; Internet ark@cs.rit.edu;Bitnet arkics@ritvax. 


Past, Present, Parallel: A Survey of Available Parallel Computing Systems 

Arthur Trew and Greg Wilson, eds. (Springer-Verlag, New York, 1991, ISBN 0-387-19664-1, 392 pp., $69) 


In the mid-1980s, researchers at the 
University of Edinburgh, under aus¬ 
pices of the UK’s Economic and So¬ 
cial Research Council, began to study 
parallel computing with respect to its 
power to change information technol¬ 
ogy. For example, the economics of 
high-performance computing prom¬ 
ised to change radically with the de¬ 
velopment of parallel architecture. 
The Edinburgh Programme on Infor¬ 
mation and Communication Technol¬ 
ogies commissioned a report based on 
this study because it saw the need for 
a thorough, up-to-date survey of par¬ 
allel computing. Past, Present, Parallel 
is an extended version of that report. 
It describes a wide range of commer¬ 
cially available parallel computers. It 
also analyzes the manufacturers of 
these machines and their position in 
the marketplace. It is unusual to find 
so much information on such a variety 
of hardware in one place. 

The book is well organized. The in¬ 
troductory chapter offers a good over¬ 
view of the complexities of parallel 
computing and would stand on its 
own. It is followed by seven chapters 
on present hardware technology and 
overviews of the companies associated 
with each: 

• SIMD (Active Memory Technolo¬ 
gy, MassPar, Thinking Machines) 


• Shared-memory multiprocessors 
(Alliant, BBN, Concurrent, Con¬ 
vex, Encore, FPS, Sequent) 

• Hypercubes (Intel, Ncube) 

• The transputer and its offspring 
(Inmos, Caplin Cybernetics, Mei- 
ko, Parsys, Parsytec) 

• New machines for new niches (Co¬ 
gent, Silicon Graphics, Stardent, 
Teradata) 

• Vector supercomputers (Cray Re¬ 
search, NEC, Supercomputer Sys¬ 
tems Inc.) 

• The giants: Biding their time 
(DEC, Fujitsu, IBM) 

The company overviews cover hard¬ 
ware, development systems, program¬ 
ming languages, market niches, com¬ 
petition, and prospects for the future. 
Hardware diagrams are provided in 
many cases. Summaries of each com¬ 
pany’s high-end equipment conclude 
each chapter and help in comparing 
the products. 

The chapters on hardware are fol¬ 
lowed by a brief discussion of soft¬ 
ware and the conflict between effi¬ 
cient code and portable code. The 
focus is on four systems that purport 
to provide portability: Express, He¬ 
lios, Linda, and Strand. The coverage 
is light — only beginning to give a fla¬ 
vor for each system, but it does at 
least do that. 


There is also a chapter devoted to 
commercial parallel computers that 
are no longer available: BiiN, Eta, 
Multiflow, Myrias, and Symult. The 
discussions include an overview of 
each machine and the company orga¬ 
nization and an analysis of why the 
company failed. These analyses pro¬ 
vide an interesting perspective on the 
viability of parallel computing and the 
economic factors that have inhibited 
its growth. The last chapter looks 
briefly into the future. Appendixes 
outline the technologies that underpin 
parallelism. 

The rate at which parallel comput¬ 
ing is changing is phenomenal. Past, 
Present, Parallel was published in late 
1991, and although it is thorough, it is 
already out of date. Some of the sys¬ 
tems described under present technol¬ 
ogy are now past (for example. Star- 
dent) and some of the systems alluded 
to in the discussions of the future are 
available today (for example, Think¬ 
ing Machines’ CM5 and Alliant’s 
Campus/800). Nevertheless, this book 
is an important reference work for 
anyone interested in parallel comput¬ 
ing, and especially for those just start¬ 
ing in the field. 

Nan Schaller 

Rochester Institute of Technology 

Rochester, N.Y. 


Programming Distributed Systems 


H.E. Bal (Silicon Press, Summit, N.J., 

This book provides an interesting 
view of programming physically dis¬ 
tributed computer systems — that is, 
systems consisting of “multiple auton¬ 
omous processors that do not share 
primary memory, but cooperate by 
sending messages over a communica¬ 
tions network.” Uniprocessors and 
multiprocessor systems that communi¬ 
cate through a shared memory are not 
included in this category. 

The author enumerates three im¬ 
portant characteristics that distinguish 
distributed systems from uniproces¬ 
sors: (1) multiple processors in a sys¬ 
tem, (2) necessary cooperation among 


1990, ISBN 0-929306-05-8, 282 pp., $29.95) 
the processors, and (3) potential for 
partial failures. 

The general goal of this book is to 
find ways of reducing the effort re¬ 
quired in writing code for distributed 
systems. The author identifies three 
general approaches to building dis¬ 
tributed applications: directly on top 
of the hardware, on top of the operat¬ 
ing system by adding appropriate li¬ 
brary calls, and independently by em¬ 
ploying a special distributed 
programming language. 

The author finally advocates the lat¬ 
ter. Nevertheless, his discussion of 
building distributed software on top 


of the operating, system is interesting. 
The examples, discussion of major is¬ 
sues, and conclusions are based on his 
experience with Amoeba, an operat¬ 
ing system developed in The Nether¬ 
lands. The author describes serious 
shortcomings of this approach in all 
major areas of distributed program¬ 
ming — parallelism, synchronization 
and communication, and fault toler¬ 
ance — and mentions several other de¬ 
ficiencies that can lead to serious prob¬ 
lems. For example, the lack of type 
checking can cause inconsistencies in 
interpreting message parameters. 

The discussion of distributed pro- 
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gramming languages is probably the 
best part of the book. Language con¬ 
structs are reviewed according to crite¬ 
ria related to the three distinguishing 
characteristics of distributed systems: 
(l)units of parallelism and mapping 
them onto hardware, (2) communica¬ 
tion primitives based on message 
passing and data sharing, and (3) prin¬ 
ciples of fault tolerance. 

The notion of process is treated as 
merely one of the computation con¬ 
structs available to express parallel¬ 
ism. The others are objects, state¬ 
ments, expressions, and clauses. 
Several languages — for example, Oc¬ 
cam, Concurrent C, SR, and Emerald 
— allow the mapping of computation 
units onto physical processors. 

The author mentions more than 40 
languages and discusses some of them 
in detail regarding the availability of 
constructs suitable for distributed pro¬ 
gramming. Rather than fully describ¬ 
ing each language, he outlines a few 
key ideas and categorizes them ac¬ 
cording to the general criterion of 
whether they provide distributed or 
shared address space. There is a good 
discussion of the most common com¬ 
munication primitives for message 
passing (asynchronous and synchro¬ 
nous message passing, rendezvous, 
and remote procedure calls). Lan¬ 
guages with logically shared address 
space (functional and logic languages, 
and those based on distributed data 


structures, like Linda.) are also given 
special attention. 

Interestingly enough, this language- 
level approach is similar to the treat¬ 
ment of concurrent programming in 
two books recently reviewed in this 
column: Principles of Concurrent and 
Distributed Programming by M. Ben- 
Ari (reviewed Nov. 1991) and Con¬ 
current Programming: Principles and 
Practice by G.R. Andrews (reviewed 
May 1992). The major difference in 
Bal’s book results from his bottom-up 
perspective on the underlying hard¬ 
ware architecture with processors 
sharing only communication chan¬ 
nels. Unlike a top-down approach 
with a computing unit that may be 
composed of separate processors, 
Bal’s approach leads to a discussion 
of fault tolerance. 

The author comes to “the unfortu¬ 
nate conclusion that no existing tech¬ 
nique or language provides a fully sat¬ 
isfactory base for distributed 
programming.” Thus he proposes de¬ 
signing a new language from scratch. 
Approximately half the book is devot¬ 
ed to describing a new model for dis¬ 
tributed programming, its supporting 
language (named Orca), the lan¬ 
guage’s implementation, and pro¬ 
gramming examples. 

The author adopts a shared data- 
object model for distributed computa¬ 
tions. This model assumes that implic¬ 
it communication (with explicit 


parallelism) has advantages over the 
message-based approach. Fault toler¬ 
ance is also implicit, as the author as¬ 
sumes only noncritical, non-real-time 
applications. In consequence, the new 
language integrates sequential and 
concurrent (distributed) programming 
constructs. It supports records, dy¬ 
namic arrays, sets, bags, and graphs. 
Global variables and pointers are 
eliminated for safety reasons. Objects 
are instances of abstract data types, 
and processes can pass them as shared 
parameters to spawned children. The 
distribution of objects among proces¬ 
sors is left to the implementation, so 
that dynamic replication of objects is 
possible. Orca is described fully and 
the description is fascinating. 

In general, the author makes a very 
interesting contribution to the field of 
distributed programming, though he 
admits that he hasn’t closed the book 
on issues of programming applications 
for distributed machines. Even though 
it concentrates on a single approach, I 
highly recommend this book to any¬ 
one who needs a good background in 
distributed programming and a sense 
of future research. I also found it use¬ 
ful in the classroom, because it pro¬ 
vides solid discussions of fundamental 
questions before taking its stand. 

Janusz Zalewski 

Southwest Texas State University 

San Marcos, Texas 


Object-Oriented Databases with Applications to CASE, Networks, and VLSI CAD 

Rajiv Gupta and Ellis Horowitz, eds. (Prentice Hall, Englewood Cliffs, N.J., 1991, ISBN 0-13-629833-8, 447 pp., $48) 


Object-oriented design is the latest 
topic in the development of large and 
dynamic software systems. It is more a 
concept than a method, and it means 
different things to different people. 
This book is therefore a timely addi¬ 
tion to the software literature. The ed¬ 
itors’ introduction is very good. It ex¬ 
plains the essence of the object- 
oriented design approach: (1) to iden¬ 
tify the objects, (2) to define classes of 
objects, and (3) to organize the hierar¬ 
chy of classes, called inheritance. 

The introduction prepares readers 
for the more formal presentation in 
Part I, where authors with slightly dif¬ 
ferent points of view offer their over¬ 
views of the subject. At first, these 
chapters seem disjointed, but eventu¬ 
ally the pieces fall into place and the 
parts become a whole. 

One strength of this book is that it 
can be read by the novice as well as 
the initiated. A novice in this context 
refers to someone who is familiar with 


database concepts, whereas an initiate 
has previous exposure to object-ori¬ 
ented software design. Some chapters 
may be difficult for novices, but the 
presentations overlap enough so that 
readers can skip chapters they are not 
comfortable with and still get a sense 
of the object-oriented database 
(OODB) landscape. 

Part II describes some OODB im¬ 
plementations and gives concise de¬ 
scriptions of someOODBs and OODB 
languages on the market, such as 
Vbase, Type Definition Language, C 
Object Processor, Object SQL, Opal/ 
GemStone, Sim, Iris, and Orion. For 
some of these systems (Statice, Vbase, 
Object SQL, and GemStone), the im¬ 
plemented present more detailed de¬ 
scriptions in separate chapters. 

Part III treats more specialized da¬ 
tabases in applications such as CAD, 
CASE, network management, a geo¬ 
graphical information system, and an 
integrated product development sys¬ 


tem. These chapters are very readable 
and connect well with the basic con¬ 
cept. They are followed by a good in¬ 
troduction to the C++ language and a 
discussion of the necessary criteria for 
calling a language object oriented. 
Two object-oriented languages, ODE 
(Object Database and Environment) 
and Ontos, are presented in detail. 

I believe the book would have bene¬ 
fited from a glossary that defined new 
terminology. Nevertheless, enough ma¬ 
terial is pulled together to shed consid¬ 
erable light on this new and important 
field of software development. Al¬ 
though the style is not uniform and 
some of the contributions suffer from 
excessive verbiage, the text as a whole 
could be useful as a graduate-level in¬ 
troductory course or as a self-study 
book for computer professionals. 

Z. Michael Benedek 
Pacemaker Data Center 
Montefiore Hospital, Bronx, N.Y. 
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Information for Authors 
Authors are requested to submit six 
copies (in English) of their double¬ 
spaced typed manuscript (maximum 
of 20 pages) with an abstract and 
keywords to Prof. Wittie by Thurs¬ 
day, October 15, 1992. The conference 
language is English and final papers 
are restricted to eight IEEE model 
pages. Each paper must be accompa¬ 
nied by a submission letter that 
indicates which one or two confer¬ 
ence areas are most relevant. If there 
are multiple authors, one author 
must be designated as responsible for 
correspondence and preparation of 
the camera-ready paper for inclusion 
in the proceedings. Please give postal 
address, email address, and tele¬ 
phone for the corresponding author. 
Authors will be notified of accep¬ 
tance by February 1,1993 and will be 
given instructions for final prepara¬ 
tion of their papers at that time. 
Submit papers to: 

Larry Wittie 

Z4400 Computer Science 

SUNY at Stony Brook 

Stony Brook, NY 11794-4400, USA 

Tel: (516) 632-8456 

Fax: (516) 632-8334 

E-mail: lw@sbcs.sunysb.edu 

Tutorials 

In addition to papers, proposals for 
one day tutorials are solicited in any 
of the conference areas. Proposals 
should be submitted to Dr. Yao-Nan 
Lien by October 1,1992. 

Submit tutorial proposals to: 

Yao-Nan Lien 

AT&T Bell Laboratories 

200 Park Plaza, Room IHP 2A340 

Naperville, IL 60566-7050, USA 

Tel: (708) 713-4318 

Fax: (708) 713-7098 

E-mail: yaonan.lien@att.com 

For more information. 

Please contact: 

Benjamin W. (Ben) Wah 
Coordinated Science Laboratory 
University of Illinois, MC228 
1101 W. Springfield Avenue 
Urbana, IL 61801-3082 
Tel: (217) 333-3516 
Fax: (217) 244-7175 
E-mail: b-wah@uiuc.edu 


Sponsored by: 

kIi IEEE Computer Society 
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The 13th International Conference on 

Distributed 
Computing 
Systems 

Pittsburgh Hilton 
Pittsburgh, Pennsylvania, USA 
May 25-28,1993 


T his conference encompasses the technical aspects of specifying, designing, 
implementing, and evaluating distributed computing systems. In such 
systems, there are multiple processing resources interconnected to cooperate 
under system-wide control with minimal reliance on centralized procedures, 
data, or hardware. The location of computing resources may span the spectrum 
from physical adjacency to geographical dispersion. The topics of interest 
include the following aspects of distributed computing systems. 


Computer Architecture and 
Distributed Shared Memory 
Cooperative Work and Artificial 
Intelligence 

Languages, Tools, and Software 
Engineering 

Distributed System Services and 
Management 

Distributed Operating Systems 


Communication Architectures 
and Protocols 

Multimedia Computing and 
Communication 
Modeling and Performance 
Evaluation 

Reliability and Fault Tolerance 
Distributed Algorithms 
Distributed Databases 
Real-Time Issues 


Organizing and Program Committees 
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Benjamin W. Wah, University 
of Illinois at Urbana, USA 
Program Chair 
LarryWittie, 

SUNY at Stony Brook, USA 
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Michel Dubois, University of 
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Polish School of New 
Information and Communica¬ 
tion Technologies, Poland 
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CHANNEL 


Editor: Will Tracz, IBM, Federal Systems Company, IV 


Distributed virtual society and the economics of sharing 


As a memory recycler, I’d like to 
share with you some thoughts on 
the economics of sharing. 

Internet/Usenet discussions on 
computer architecture have debated 
whether 64-bit addresses will be 
useful. Aside from electronic and 
system trade-offs, there is a social 
aspect to 64-bit addressing. That 
much address space, I’ve always in¬ 
tuitively felt, should be shared. 

The formal term for this architec¬ 
ture venue is shared distributed 
memory. Assuming that this distrib¬ 
uted memory can be implemented 
worldwide and that the technologi¬ 
cal and political climate (see Sena¬ 
tor A1 Gore’s remarks in the Sep¬ 
tember 1991 issue of Scientific 
American) will exist for its imple¬ 
mentation, there could be some sur¬ 
prising consequences. 

First, the amount of code, text, 
and data available to the public on 
Internet stands at more than 50 gi¬ 
gabytes. Hence, 64-bit addresses 
would be a convenient mechanism 
for roaming existing public archives. 

Given that much data, would it be 
better to place it on disk or in sili¬ 
con? Silicon costs about $40 per 
megabyte, and magnetic disks about 
$2 per megabyte. Thus, reusability 
in excess of 20 to 1 can justify a sin¬ 
gle RAM/ROM copy versus multi¬ 
ple magnetic disk copies. Also, the 
total cost of 50 Gbytes in silicon is 
affordable, especially since the orig¬ 
inators would likely cover the cost. 


Fast access. The other major fac¬ 
tor is that the best disks offer access 
times of about 30 milliseconds (posi¬ 
tioning time, plus one revolution) to 
read a track of data. In 30 ms, light 
travels through about 3,700 miles of 
fiber. If gigahertz-bandwidth fiber 
strings all computers together, it will 
be faster to access data residing in a 
remote silicon archive than to access 
a copy on a workstation disk. 

Reusing data will become the 
norm, as a result of the speed at 
which remote archives of silicon- 
based data can be retrieved via a 
federally subsidized fiber network. 
(The issue of whether such a net¬ 
work should be federally subsidized 
may be forced. Most projects of 
such common use become utilities, 
owned and operated for the public 
good. International competitive 
pressures are likely to reward the 
country with the most useful and/or 
appropriate social-good/method-of- 
revenue trade-off.) Public-domain 
data will become a cultural re¬ 
source, taken for granted and em¬ 
ployed without hesitation. 

Given existing costs and a politi¬ 
cal desire to provide a national in¬ 
formation utility, there is the pros¬ 
pect that diskless workstations will 
become a sufficient tool of access. 
The demand for CD-ROMs and disk 
drives is not likely to shrink, since 
private information will obviously 
also exist. 

Thus, the hypermedia society of 


the not-too-distant future can be 
based on 64-bit addressing of remote 
silicon archives through a low-cost 
high-speed fiber network. Access to 
these archives can be treated as mem¬ 
ory accesses to a tertiary cache. Not 
only will it be cost effective but re¬ 
sponse times and, therefore, produc¬ 
tivity will be better than with rotating 
equivalents. (The availability of very 
fast access — under 1 ms — to locally 
available data from civic organiza¬ 
tions, universities, and hospitals al¬ 
lows room for some new avenues in 
computer usage.) 

Geographic strategy. For ease of 
switching-center design, it would be 
best to allocate the addresses geo¬ 
graphically. As people moved, their 
workstation public address region 
would change. Presumably, a name 
server would keep a current map be¬ 
tween user IDs and one’s public ad¬ 
dress region. (This assumes anyone 
could participate in operating public- 
domain archives.) 

Imagine all the world’s literature 
being organized and indexed within 
this large address space. Every indi¬ 
vidual who could afford a personal 
workstation could roam through the 
data and investigate freely. 

I can’t predict what kind of culture 
would result. Games would be popu¬ 
lar with the young, as they are now. 
Scientific work would proceed fever¬ 
ishly. The more elaborate works of 
man (such as movies, operas, and 
symphonies) would be less available 
than textual material because of sili¬ 
con costs and memory limitations. (A 
compressed two-hour video would oc¬ 
cupy about a Gbyte of memory. I sup¬ 
pose the memory for a movie could be 
spread across the address regions of 
all those who worked on the particu¬ 
lar movie.) 

You can take it from there. 

James Brakefield 

San Antonio, Texas 

braker@lonestar.utsa.edu 


“The Open Channel” is exactly what the name implies: a forum for the free ex¬ 
change of technical ideas. Try to hold your contributions to one page maximum in 
the final magazine format (about 850 words). 

We’ll accept anything (short of libel or obscenity), so long as it’s submitted by a 
member of the IEEE Computer Society. If it's really bizarre, we may ask you to get 
another member to cosponsor your contribution. 

Send everything to Will Tracz at the address above. 
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Notice 


We've been asked to make it very clear that 

THERE’S A WHALE OF A DIFFERENCE BETWEEN QNX® AND UNIX? 

WE’RE GLAD TO OBLIGE. 


Even though the QNX Realtime 
operating System is not based 

ON UNIX SOURCE CODE, WE CAN 
UNDERSTAND HOW SOME DEVELOPERS 
MIGHT CONFUSE THE TWO. AFTER ALL, 
QNX FOLLOWS THE LATEST IEEE 
POSIX 1003.1 AND 1003.2 OPEN 
SYSTEMS STANDARDS, SO YOU GET 
THE SAME API AND UTILITY SET 
FOUND IN MANY UNIX SYSTEMS. 

BUT LOOK BENEATH THE SURFACE 
AND YOU'LL SEE TWO 
FUNDAMENTALLY DISTINCT 
ARCHITECTURES. A MONOLITHIC OS 
ON THE ONE HAND, A MICROKERNEL 
OS ON THE OTHER. THEY'RE 
DIFFERENT SPECIES ALTOGETHER, 

AS DIFFERENT AS A WHALE AND 
A SCHOOL OF DOLPHINS. 

ARCHITECTURE YOU CAN BUILD ON 

QNX'S MODULAR, MICROKERNEL 
ARCHITECTURE GIVES YOU 
REMARKABLE FLEXIBILITY. OS 
SERVICES ARE PROVIDED BY A TEAM 
OF COOPERATING PROCESSES RATHER 
THAN BY A MASSIVE MONOLITHIC 

kernel. The result? You can 

STRIP QNX DOWN TO A ROM-ABLE 
EMBEDDED SYSTEM. OR BUILD IT UP 
TO A VAST NETWORK AND HARNESS 
THE POWER OF HUNDREDS OF CPUS. 


OUR PRICING IS MODULAR TOO, 
SO YOU'RE NOT FORCED TO PAY 
FOR WHAT YOU DON'T NEED. 

REALTIME PERFORMANCE 

YOU CAN COUNT ON 
NEED THE SPEED OF A FAST, 
REALTIME EXECUTIVE? 

QNX CLOCKS IN AT 16 |ASEC 
PER CONTEXT SWITCH ON 
A 33 MHZ 80486. 

BUT QNX DOESN'T STOP THERE. 
WITH ITS PRIORITY-DRIVEN, 
PREEMPTIVE SCHEDULING, 
YOU CAN BUILD REAL REALTIME 
SOLUTIONS. 

DISTRIBUTED PROCESSING 

YOU CAN BET ON 
QNX CAN TRANSFORM A BUNCH 
OF ISOLATED MACHINES INTO A 
SEAMLESS SUPERCOMPUTER, 



<£$3 


ORCHESTRATING HUNDREDS OF 
CPUS WITH ITS NETWORK-WIDE IPC. 
YOU'RE IN COMPLETE CONTROL 
OF ALL RESOURCES AT ANY POINT, 
FROM THE PLANT FLOOR 
RIGHT UP TO YOUR DESKTOP. 

Support You Can Depend On 

DURING THE LAST TEN YEARS, 
WE'VE EARNED A REPUTATION 
FOR OUTSTANDING TECHNICAL 
SUPPORT. WE OFFER EVERYTHING 
FROM 24-HOUR ONLINE 
CONFERENCING TO ONSITE 
CONSULTING, SO YOU CAN EASILY 
REACH THE PEOPLE WHO MAKE UP 
THE QNX DEVELOPMENT TEAM. 

THEIR EXPERTISE CAN HELP 
YOU KEEP YOUR DEVELOPMENT 
PROJECTS RIGHT ON COURSE. 

TO FIND OUT HOW YOUR 
APPLICATIONS CAN THRIVE IN 
THE QNX ENVIRONMENT, 
CALL 1-800-363-9001, 
(EXT. 108). 

Quantum Software Systems ltd. 
175 Terrence Matthews crescent 
Kanata, Ontario, Canada 
K2M 1W8 
TEL: 613-591-0931 
FAX: 613-591-3579 
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AND 

CONFERENCES 

5TH USENIX C++ CONFERENCE 

PROGRAM CHAIR: Jonathan Shopiro, UNIX System Laboratories, Inc. 

Devoted exclusively to C++, this conference will cover present applications and future applications. 
Two days of tutorials and two days of refereed paper sessions are offered along with one evening of 
Birds-of-a-Feather sessions. A vendor display will be open one evening. 

AUGUST 10-13 

1992 

MARRIOTT HOTEL, 
PORTLAND, OREGON 

3RD USENIX UNIX SECURITY SYMPOSIUM 

■ PROGRAM CHAIR: Edward DeHart, Computer Emergency Response Team, Software 

Engineering Institute, Carnegie Mellon University 

Security as it relates to networks and the UNIX operating system will be examined in this 3-day 
symposium. A day of tutorials and two days of refereed papers, invited talks, and panel sessions, will 
be accompanied by two evenings of Birds-of-a-Feather and Work-in-Progress sessions. 

SEPTEMBER 14-16 

1992 

SHERATON INNER 

HARBOR, 

BALTIMORE, MARYLAND 

6TH USENIX SYSTEMS ADMINISTRATION CONFERENCE (USA VI) 

m PROGRAM CHAIR: Trent Hein, XOR Computer Systems 

The needs of system administrators, for both large and small installations, will be the focus at LISA VI. 

A dual-track tutorial program, featuring both introductory and advanced topics, will be offered the first 
two days followed by a three-day technical conference. A vendor display will be open one evening. 

OCTOBER 19-23 

1992 

SHERATON HOTEL, 

LONG BEACH, CALIFORNIA 

USENIX WINTER 1993 GENERAL CONFERENCE 

■ GENERAL CHAIR: Rob Kolstad, Berkeley Software Design, Inc. 
m TECHNICAL PROGRAM CHAIR: Dan Geer, Geer Zolot Associates 
m DATES FOR REFEREED PAPER SUBMISSIONS: 

Extended Abstracts Due: July 20, 1992; Notifications to Authors: August 19, 1992 

Final Papers Due: November 20, 1992 

JANUARY 25-29 

1993 

TOWN & COUNTRY HOTEL, 

SAN DIEGO, CALIFORNIA 

USENIX SUMMER 1993 GENERAL CONFERENCE 

■ PROGRAM CHAIR: David S.H. Rosenthal, SunSoft, Inc. 
m DATES FOR REFEREED PAPER SUBMISSIONS: 

Extended Abstracts Due: February 2, 1993; 

Final Papers Due: March 30, 1993 
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PjUNE 21-25 J j 

1993 

CINCINNATI CONVENTION 
CENTER 

CINCINNATI, OHIO | 

TO RECEIVE FULL INFORMATION 

. PLEASE CONTACT: 

USENIX Conference Office, 22672 Lambert St., Suite 613, El Toro, CA 92630 
(714) 588-8649, FAX (714) 588-9706, Email: conference@usenix.org 
■ USENIX, the UNIX and Advanced Computing Systems Professional and Technical Association 
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